qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v4 1/4] Add options to config/meson files for custom CSR


From: Alistair Francis
Subject: Re: [RFC PATCH v4 1/4] Add options to config/meson files for custom CSR
Date: Fri, 13 Aug 2021 15:11:00 +1000

On Fri, Aug 6, 2021 at 11:54 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Fri, Aug 6, 2021 at 8:58 PM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> >
> > > On Fri, Aug 6, 2021 at 10:39 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > On Fri, Aug 6, 2021 at 1:57 AM Ruinland Chuan-Tzu Tsai
> > > > <ruinland@andestech.com> wrote:
> > > > >
> > > > > From: Ruinland ChuanTzu Tsai <ruinland@andestech.com>
> > > > >
> > > > > Adding option `riscv_custom` to configure script, meson.build and
> > > > > meson_options.txt so as to toggle custom CSR and will-be-upstreamed 
> > > > > custom
> > > > > instructions handling logic.
> > > > >
> > > > > Signed-off-by: Dylan Jhong <dylan@andestech.com>
> > > > > ---
> > > > >  configure         | 6 ++++++
> > > > >  meson.build       | 2 ++
> > > > >  meson_options.txt | 2 ++
> > > > >  3 files changed, 10 insertions(+)
> > > > >
> > > >
> > > > This sounds like unnecessary to bring such a config option to the meson 
> > > > level.
> > > >
> > > > I believe a Kconfig option should just be fine.
> > >
> > > +Alistair
> >
> > I don’t see why this is even a config option. If you request a vendor’s
> > CPU you should get any custom CSRs defined for that vendor’s CPU. If
> > you don’t you don’t. This should be purely a run-time thing, no?
>
> In a generic use case where we build all RISC-V machines into one
> qemu-system-riscv{32,64} executable this makes no difference. The
> Kconfig option will be turned on if any one of the machines requires
> it. It only gets benefits when we build a QEMU executable on a
> per-machine basis.

I agree with Bin that this could be a Kconfig option, that is selected
when a vendor CPU is enabled.

It also doesn't have to be a config and could just be built all the
time. I don't see much of an advantage in allowing it to be disabled,
it's just another thing we would need to test. Maybe is a user was
just interested in the virt machine/KVM they could disable it to avoid
any overhead.

Alistair

>
> Regards,
> Bin
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]