[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
>