[PATCH] RISC-V: Allow the used to downgrade to sv48 when HW supports sv57

[Geert Uytterhoeven]

Hi Anup,

On Mon, Apr 25, 2022 at 4:14 PM Anup Patel <apatel at ventanamicro.com> wrote:
> On Mon, Apr 25, 2022 at 7:06 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > On Mon, Apr 25, 2022 at 3:14 PM Anup Patel <apatel at ventanamicro.com> wrote:
> > > On Mon, Apr 25, 2022 at 6:12 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > > On Fri, Apr 22, 2022 at 11:42 PM Palmer Dabbelt <palmer at rivosinc.com> 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 at rivosinc.com>
> > > > > ---
> > > > > 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 at canonical.com
> > > >
> > > > 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?
>
> Usually, HW vendors will use different names for incrementally
> improving implementations so they will tend to create separate
> dts/dtsi files for newer implementations with some sharing via
> common dtsi files.

Even for a minor update of the SoC to fix some errata, where newer
boards just contain a newer revision of the silicon?

> > > 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?
>
> The MMU modes are detected very early and even before the kernel
> command-line is parsed.

That can be fixed.

> > If you want it in your DTB, you can add it to chosen/bootargs.
>
> If HW vendor describe complete details in DT and disables few
> things in chosen/bootargs then it means there is some issue with
> those things disabled via chosen/bootargs.
>
> A HW vendor might never want to advertise broken extensions in
> their implementation so the ISA string and various HART features
> in DT will be set based on working functionality on real hardware.

That may be true in a perfect world.
Depending on the level of brokenness, the issue may not be detected
before devices are released into the world.  So you're better prepared
for such cases.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

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