[RFT 1/2] RISC-V: handle missing "no-map" properties for OpenSBI's PMP protected regions

[Prabhakar Mahadev Lad]

> -----Original Message-----
> From: Conor Dooley <conor at kernel.org>
> Sent: Tuesday, December 19, 2023 6:58 PM
> To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj at bp.renesas.com>; Palmer Dabbelt
> <palmer at dabbelt.com>
> Cc: Conor Dooley <conor.dooley at microchip.com>; prabhakar.csengg at gmail.com; geert+renesas at glider.be;
> Atish Patra <atishp at rivosinc.com>; Paul Walmsley <paul.walmsley at sifive.com>; apatel at ventanamicro.com;
> alexghiti at rivosinc.com; Bjorn Topel <bjorn at rivosinc.com>; suagrfillet at gmail.com;
> jeeheng.sia at starfivetech.com; petrtesarik at huaweicloud.com; linux-riscv at lists.infradead.org; linux-
> kernel at vger.kernel.org; stable at vger.kernel.org
> Subject: RE: [RFT 1/2] RISC-V: handle missing "no-map" properties for OpenSBI's PMP protected regions
> 
> 
> 
> On 19 December 2023 18:38:30 GMT, Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj at bp.renesas.com>
> wrote:
> >Hi Palmer,
> >
> >> -----Original Message-----
> >> From: Palmer Dabbelt <palmer at dabbelt.com>
> >> Sent: Tuesday, December 19, 2023 6:07 PM
> >> To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj at bp.renesas.com>
> >> Cc: Conor Dooley <conor at kernel.org>; Conor Dooley
> >> <conor.dooley at microchip.com>; prabhakar.csengg at gmail.com;
> >> geert+renesas at glider.be; Atish Patra <atishp at rivosinc.com>; Paul
> >> Walmsley <paul.walmsley at sifive.com>; apatel at ventanamicro.com;
> >> alexghiti at rivosinc.com; Bjorn Topel <bjorn at rivosinc.com>;
> >> suagrfillet at gmail.com; jeeheng.sia at starfivetech.com;
> >> petrtesarik at huaweicloud.com; linux-riscv at lists.infradead.org;
> >> linux-kernel at vger.kernel.org; stable at vger.kernel.org
> >> Subject: RE: [RFT 1/2] RISC-V: handle missing "no-map" properties for
> >> OpenSBI's PMP protected regions
> >>
> >> On Tue, 19 Dec 2023 09:27:42 PST (-0800), prabhakar.mahadev-lad.rj at bp.renesas.com wrote:
> >> > Hi Conor,
> >> >
> >> >> -----Original Message-----
> >> >> From: Conor Dooley <conor at kernel.org>
> >> >> Sent: Tuesday, December 19, 2023 5:18 PM
> >> >> To: Conor Dooley <conor.dooley at microchip.com>
> >> >> Cc: Lad, Prabhakar <prabhakar.csengg at gmail.com>; Palmer Dabbelt
> >> >> <palmer at dabbelt.com>;
> >> >> geert+renesas at glider.be; Atish Patra <atishp at rivosinc.com>; Paul
> >> >> geert+Walmsley <paul.walmsley at sifive.com>;
> >> >> apatel at ventanamicro.com; alexghiti at rivosinc.com; Bjorn Topel
> >> >> <bjorn at rivosinc.com>; suagrfillet at gmail.com;
> >> >> jeeheng.sia at starfivetech.com; petrtesarik at huaweicloud.com; linux-
> >> >> riscv at lists.infradead.org; linux-kernel at vger.kernel.org;
> >> >> stable at vger.kernel.org; Prabhakar Mahadev Lad
> >> >> <prabhakar.mahadev-lad.rj at bp.renesas.com>
> >> >> Subject: Re: [RFT 1/2] RISC-V: handle missing "no-map" properties
> >> >> for OpenSBI's PMP protected regions
> >> >>
> >> >> Hey,
> >> >>
> >> >> On Thu, Dec 07, 2023 at 01:11:23PM +0000, Conor Dooley wrote:
> >> >> > On Thu, Dec 07, 2023 at 01:02:00PM +0000, Lad, Prabhakar wrote:
> >> >> > > On Wed, Dec 6, 2023 at 2:26 PM Conor Dooley <conor at kernel.org> wrote:
> >> >> > > > On Wed, Dec 06, 2023 at 04:52:11AM -0800, Palmer Dabbelt wrote:
> >> >> > > > > On Thu, 10 Aug 2023 02:07:10 PDT (-0700), Conor Dooley wrote:
> >> >> >
> >> >> > > > > > I'm perfectly happy to drop this series though, if
> >> >> > > > > > people generally are of the opinion that this sort of firmware workaround is ill-
> advised.
> >> >> > > > > > We are unaffected by it, so I certainly have no pressure
> >> >> > > > > > to have something working here. It's my desire not to be
> >> >> > > > > > user-hostile that motivated this patch.
> >> >> > > > >
> >> >> > > > > IIUC you guys and Reneas are the only ones who have
> >> >> > > > > hardware that might be in a spot where users aren't able
> >> >> > > > > to update the firmware (ie, it's out in production somewhere).
> >> >> > > >
> >> >> > > > I dunno if we can really keep thinking like that though. In
> >> >> > > > terms of people who have devicetrees in the kernel and stuff
> >> >> > > > available in western catalog distribution, sure.
> >> >> > > > I don't think we can assume that that covers all users
> >> >> > > > though, certainly the syntacore folks pop up every now and
> >> >> > > > then, and I sure hope that Andes etc have larger customer
> >> >> > > > bases than the in-kernel users would suggest.
> >> >> > > >
> >> >> > > > > So I'm adding Geert, though he probably saw this months ago...
> >> >> > > >
> >> >> > > > Prabhakar might be a good call on that front. I'm not sure
> >> >> > > > if the Renesas stuff works on affected versions of OpenSBI
> >> >> > > > though, guess it depends on the sequencing of the support
> >> >> > > > for the non-coherent stuff and when this bug was fixed.
> >> >> > > >
> >> >> > > ATM, I dont think there are any users who are using the
> >> >> > > upstream kernel + OpenSBI (apart from me and Geert!).
> >> >> > > Currently the customers are using the BSP releases.
> >> >> >
> >> >> > That doesn't really answer whether or not you (and your
> >> >> > customers) are using an affected version of the vendor OpenSBI?
> >> >> > The affected range for OpenSBI itself is [v0.8 to v1.3).
> >> >>
> >> >> Did you perhaps miss this mail Prabhakar?
> >> >>
> >> > Oops sorry for that.
> >> >
> >> > I can confirm the BSP version used by the customers is v1.0 [0].
> >> >
> >> > [0]
> >> > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
> >> > ith%2F&data=05%7C02%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com%7C6
> >> > 3259d3bbda343ccde3e08dc00c46054%7C53d82571da1947e49cb4625a166a4a2a%
> >> > 7C0%7C0%7C638386090629864750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> >> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> >> > C&sdata=xebpQgqY9W03HSDdoL0Si2taJ2RkOgTiR8H6koSKNq8%3D&reserved=0
> >> > ub.com%2Frenesas-rz%2Frz_opensbi%2Fcommits%2Fwork%2FOpenSBI-PMA%2F&
> >> > dat
> >> > a=05%7C02%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com%7C014cf4ddfd1
> >> > e48
> >> > 1ff5bc08dc00bd467f%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C638
> >> > 386
> >> > 060130410731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> >> > luM
> >> > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=a0tcsXY4EQl
> >> > ODi
> >> > I34QygXS9QpJnVBqL8bNkxE8N5J2g%3D&reserved=0
> >>
> >> OK, so sounds like would end up with broken systems from this bug, then?
> >>
> >> IIRC we still have the Renesas systems as NONPORTABLE due to that DMA
> >> pool Kconfig conflict.  So if it's really only these Renesas systems
> >> that have the bug, maybe we can still remove hibernation from
> >> NONPORTABLE and just add in some sort of Kconfig to disable the
> >> Renesas+hibernation combinations that would break?
> >>
> >Well customers using BSP uses v1.0 for OpenSBI and kernel 5.10-cip, and people wanting to run
> upstream kernel will have to only use the upstream OpenSBI as the OpenSBI used in BSP is not
> compatible with upstream kernel(Linux doesn’t bootup).
> >
> >ATM I can say that its only me and Geert using upstream OpenBSI and upstream kernel.
> >
> >With that in mind would we still require that change?
> 
> 5.10 doesn't have hibernation support in it, although I'm not sure why anyone would really want to use
> a kernel that old with a RISC-V system.
> 
At Renesas we have the BSPs based on the CIP kernel. Currently the BSPs are based on 5.10-cip [0] (we plan to upgrade it to 6.1-cip).

> The upstream versions of opensbi that support the renesas stuff have the no-map fix, right?
> If that's the case, then nothing special config wise is likely required.
> 
Yes it does.

> I'm still wary of other systems though, we are acting as if it is only Microchip and Renesas are the
> "real" users.

[0] https://gitlab.com/cip-project/cip-kernel/linux-cip/-/tree/linux-5.10.y-cip?ref_type=heads

Cheers,
Prabhakar