Re: [PATCH v3 5/5] irqchip/gic-v3: Enable non-coherent redistributors/ITSes ACPI probing

[Marc Zyngier]

On Wed, 18 Oct 2023 09:42:14 +0100,
Lorenzo Pieralisi <lpieralisi@xxxxxxxxxx> wrote:
> 
> On Tue, Oct 17, 2023 at 05:44:28PM +0100, Marc Zyngier wrote:
> > On Tue, 17 Oct 2023 15:19:46 +0100,
> > Lorenzo Pieralisi <lpieralisi@xxxxxxxxxx> wrote:
> > > 
> > > On Fri, Oct 06, 2023 at 02:59:29PM +0200, Lorenzo Pieralisi wrote:
> > > > The GIC architecture specification defines a set of registers
> > > > for redistributors and ITSes that control the sharebility and
> > > > cacheability attributes of redistributors/ITSes initiator ports
> > > > on the interconnect (GICR_[V]PROPBASER, GICR_[V]PENDBASER,
> > > > GITS_BASER<n>).
> > > > 
> > > > Architecturally the GIC provides a means to drive shareability
> > > > and cacheability attributes signals and related IWB/OWB/ISH barriers
> > > > but it is not mandatory for designs to wire up the corresponding
> > > > interconnect signals that control the cacheability/shareability
> > > > of transactions.
> > > > 
> > > > Redistributors and ITSes interconnect ports can be connected to
> > > > non-coherent interconnects that are not able to manage the
> > > > shareability/cacheability attributes; this implicitly makes
> > > > the redistributors and ITSes non-coherent observers.
> > > > 
> > > > So far, the GIC driver on probe executes a write to "probe" for
> > > > the redistributors and ITSes registers shareability bitfields
> > > > by writing a value (ie InnerShareable - the shareability domain the
> > > > CPUs are in) and check it back to detect whether the value sticks or
> > > > not; this hinges on a GIC programming model behaviour that predates the
> > > > current specifications, that just define shareability bits as writeable
> > > > but do not guarantee that writing certain shareability values
> > > > enable the expected behaviour for the redistributors/ITSes
> > > > memory interconnect ports.
> > > > 
> > > > To enable non-coherent GIC designs on ACPI based systems, parse the MADT
> > > > GICC/GICR/ITS subtables non-coherent flags to determine whether the
> > > > respective components are non-coherent observers and force the shareability
> > > > attributes to be programmed into the redistributors and ITSes registers.
> > > > 
> > > > An ACPI global function (acpi_get_madt_revision()) is added to retrieve
> > > > the MADT revision, in that it is essential to check the MADT revision
> > > > before checking for flags that were added with MADT revision 7 so that
> > > > if the kernel is booted with ACPI tables (MADT rev < 7) it skips parsing
> > > > the newly added flags (that should be zeroed reserved values for MADT
> > > > versions < 7 but they could turn out to be buggy and should be ignored).
> > > > 
> > > > Signed-off-by: Lorenzo Pieralisi <lpieralisi@xxxxxxxxxx>
> > > > Cc: Robin Murphy <robin.murphy@xxxxxxx>
> > > > Cc: Mark Rutland <mark.rutland@xxxxxxx>
> > > > Cc: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
> > > > Cc: Marc Zyngier <maz@xxxxxxxxxx>
> > > > ---
> > > >  drivers/acpi/processor_core.c    | 21 +++++++++++++++++++++
> > > >  drivers/irqchip/irq-gic-common.h |  8 ++++++++
> > > >  drivers/irqchip/irq-gic-v3-its.c |  4 ++++
> > > >  drivers/irqchip/irq-gic-v3.c     |  9 +++++++++
> > > >  include/linux/acpi.h             |  3 +++
> > > >  5 files changed, 45 insertions(+)
> > > 
> > > Hi Marc,
> > > 
> > > just a quick note to ask if, from an ACPI binding POW
> > 
> > I guess you mean POV. POW has an entirely different meaning... :-/
> > 
> > > this patch and related approach make sense to you.
> > > 
> > > If so, we can start the process to get the ACPI changes drafted
> > > in:
> > > 
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=4557
> > > 
> > > and deployed in this patch into the ACPI specs, I can log
> > > an "ACK" in the tianocoreBZ entry above (we will be able to
> > > rework the code as much as we want, this is just for the
> > > bindings).
> > 
> > I'm OK with the overall shape of it. However, I wonder what the
> > rationale is for spreading the redistributor property all over the map
> > (in both GICC and GICR structures), while it could be set once and for
> > all in the core MADT flags (32 bits, of which only one is in use).
> > 
> > It is bad enough that there are two ways of getting the GICR regions.
> > Why can't the properties that apply to all of the be common?
> 
> I don't think we are allowed to add arch specific flags to the MADT
> since those, supposedly, are cross-architecture (and the only one
> defined is quite old, though x86 specific).

There is nothing that is truly cross-arch in this table. *everything*
in MADT is arch-specific.

> The reason behind spreading the property is the nature of GICC/GICR
> subtables themselves - we wanted to apply flags only in subtables
> relevant to the components in question.
>
> We could try to add a global flag to the MADT but I would not be
> surprised if the ECR would be rejected then for the reason I explained
> above.

I don't think that's much of a reason, but I really don't care enough
about this to argue otherwise.

	M.

-- 
Without deviation from the norm, progress is not possible.