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

[Palmer Dabbelt]

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 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://github.com/renesas-rz/rz_opensbi/commits/work/OpenSBI-PMA/

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?

> 
> Cheers,
> Prabhakar