Hi Anup,
On Mon, Apr 25, 2022 at 3:14 PM Anup Patel <apatel@xxxxxxxxxxxxxxxx> wrote:
> On Mon, Apr 25, 2022 at 6:12 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > On Fri, Apr 22, 2022 at 11:42 PM Palmer Dabbelt <palmer@xxxxxxxxxxxx> wrote:
> > > Similar to the previous patch, this allows a dt-selected downgrade to
> > > sv48 on systems that support sv57 in case users don't need the extra VA
> > > bits and want to save memory or improve performance.
> > >
> > > Signed-off-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>
> > > ---
> > > This is on top of the patches from Alex's set that I dropped.
> >
> > You mean "[PATCH v3 13/13] riscv: Allow user to downgrade to sv39
> > when hw supports sv48 if !KASAN"?
> > 20211206104657.433304-14-alexandre.ghiti@xxxxxxxxxxxxx
> >
> > For both: "DT describes hardware, not software policy"?
>
> It is possible that HW is designed to support both Sv48 and Sv39 but
> there is some errata due to which Sv48 does not work correctly ?
In that case, I assume the software has to disable Sv48 on its own?
Fixed hardware should use a different compatible value, so software
will know when the issue is fixed, and the feature can be used.
How else is DTB backwards-compatibility supposed to work?
> We should allow users to downgrade the MMU mode, due to
> their own reasons. In fact, users can also disable an extension
> by not showing it in the DT ISA string.
That sounds like a software policy, too.
What is wrong with a kernel command line option?
If you want it in your DTB, you can add it to chosen/bootargs.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
