Message-ID: <CAFEAcA-=0GWG+rnHDOnsHg8cUq1pszN=x1-W+4MYZXXD8H8Pkg@mail.gmail.com>
Date: Thu, 29 May 2025 15:30:51 +0100
From: Peter Maydell <peter.maydell@...aro.org>
To: Lorenzo Pieralisi <lpieralisi@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, andre.przywara@....com, 
	Arnd Bergmann <arnd@...db.de>, Sascha Bischoff <sascha.bischoff@....com>, 
	Timothy Hayes <timothy.hayes@....com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
	Mark Rutland <mark.rutland@....com>, Jiri Slaby <jirislaby@...nel.org>, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org
Subject: Re: [PATCH v4 01/26] dt-bindings: interrupt-controller: Add Arm GICv5

On Thu, 29 May 2025 at 15:21, Lorenzo Pieralisi <lpieralisi@...nel.org> wrote:
> On Thu, May 29, 2025 at 02:17:26PM +0100, Peter Maydell wrote:
> > The dt bindings do allow for describing Secure-world devices:
> > Documentation/devicetree/bindings/arm/secure.txt has the
> > details. We use this in QEMU so we can provide a DTB to
> > guest EL3 firmware that tells it where the hardware is
> > (and which EL3 can then pass on to an NS kernel). It would
> > be helpful for the GICv5 binding to be defined in a way that
> > we can do this for a GICv5 system too.
> >
> > > Two questions:
> > >
> > > - I don't have to spell out the IRS/ITS config frame (and SETLPI, by
> > >   the way) as non-secure, since that's implicit, is that correct ?
> >
> > Do you want the DT binding to handle the case of "CPU and GIC do not
> > implement EL3, and the only implemented security state is Secure"
> > without the kernel needing to do something different from "ditto ditto
> > but the only implemented security state is Nonsecure" ?
>
> Not sure I follow you here sorry :)

In a hypothetical system like that the dt could either
define the (only) IRS frame in reg[], or in secure-reg[].
The former would let the kernel not care about the fact it was
in Secure, but would be a bit weird. But I think we can probably
ignore this hypothetical in favour of keeping the binding simple.

> > (Currently booting.html says you must be in NS, so we effectively
> > say we don't support booting on this particular unicorn :-)
> > But the secure.txt bindings envisage "kernel got booted in S",
> > mostly for the benefit of aarch32.)
> >
> > > - How can the schema describe, if present, EL3, Secure and Realm frames ?
> >
> > The tempting thing to do is to have regs[] list the frames
> > in some given order, but the spec makes them not simple
> > supersets, allowing all of:
> >  * NS
> >  * S
> >  * NS, S, EL3
> >  * NS, Realm, EL3
> >  * NS, Realm, S, EL3
> >
> > secure.txt says:
> > # The general principle of the naming scheme for Secure world bindings
> > # is that any property that needs a different value in the Secure world
> > # can be supported by prefixing the property name with "secure-". So for
> > # instance "secure-foo" would override "foo".
> >
> > So maybe we could have
> >  reg : the NS frame(s)
> >  secure-reg : the S frame(s)
> >  realm-reg : the Realm frame(s)
> >  root-reg : the EL3 frame(s)
> >
> > ??
>
> I assume someone has to write the root/realm binding extensions.
>
> In Documentation/devicetree/bindings/arm/secure.txt I don't think that
> reg is a contemplated property - I don't know if the list of properties
> is up-to-date.

It's up to date in the sense that so far we've only needed
to have the 'status' property have a secure- variant. My
suggestion here is that we might extend that to also allow
secure-reg, and to have root- and realm- prefixes too.
Though I don't think we would want to permit secure-reg for
any old device, so maybe something more-GICv5-specific would
work better.

thanks
-- PMM

Powered by blists - more mailing lists