Messages in this thread | | | From | Anup Patel <> | Date | Thu, 23 Sep 2021 17:35:52 +0530 | Subject | Re: [PATCH] riscv: Add RISC-V svpbmt extension |
| |
On Thu, Sep 23, 2021 at 5:21 PM Alexandre Ghiti <alexandre.ghiti@canonical.com> wrote: > > On Thu, Sep 23, 2021 at 12:11 PM Nick Kossifidis <mick@ics.forth.gr> wrote: > > > > Στις 2021-09-23 13:04, Philipp Tomsich έγραψε: > > > > > > How if we expand this to a mmu subnode in cpu@x and add a booleans for > > > adornments like svnapot and svpbmt? > > > The older mmu-type could then treated to indicate a mmu w/o any > > > adornments specified. I am aware that this generates an additional > > > parsing-path that will be maintained, but it will allow future > > > properties to be grouped. > > > > > > cpu@0 { > > > ... > > > mmu { > > > type = "riscv,sv39"; > > > supports-svpbmt; > > > } > > > ... > > > } > > > > I was about to propose the same thing, we can do this now without > > breaking backwards compatibility, we don't really use mmu-type property > > at this point, we are either sv39 or nommu. > > Indeed, this property is only informative and not useful since we can > directly "ask" the hw what it supports (cf sv48 patchset). And it > cannot actually be used to force a certain svXX since reading the > device tree happens way too late in the boot process (I have this > issue with my sv48 patchset where I used to read the device tree to > set the size of the address space, but it actually breaks KASAN). > > Isn't there a way to know if it supports svPBMT at runtime?
Unfortunately, we can't detect Svpmbt through CSR read/write or traps.
A DT property seems to be the only way for Svpmbt.
Regards, Anup
> > Alex > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv
| |