linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Sunil Muthuswamy <sunilmut@microsoft.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	Michael Kelley <mikelley@microsoft.com>,
	Boqun Feng <Boqun.Feng@microsoft.com>,
	KY Srinivasan <kys@microsoft.com>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [EXTERNAL] Re: [RFC 1/1] irqchip/gic-v3-its: Add irq domain and chip for Direct LPI without ITS
Date: Sat, 31 Jul 2021 10:52:28 +0100	[thread overview]
Message-ID: <87tuka24kj.wl-maz@kernel.org> (raw)
In-Reply-To: <MW4PR21MB2002E51429F7E13B61A34FFEC0E89@MW4PR21MB2002.namprd21.prod.outlook.com>

On Mon, 26 Jul 2021 16:33:39 +0100,
Sunil Muthuswamy <sunilmut@microsoft.com> wrote:

[...]

> > I also want to understand *how* you are going to plumb this into both
> > ACPI and DT, given that neither understand how to link a PCI endpoint
> > to a set of RDs.
> > 
> > 	M.
> 
> One way to do this for NUMA-aware systems would be to use the NUMA
> related information that is available with PCI endpoints or root complex, to
> pick a Redistributor/CPU that is in the NUMA node, as specified by the PCI
> endpoint/root complex. In DT PCI devices can specify this using
> 'numa-node-id' and in ACPI using the '_PXM (Proximity)'. For systems that
> are not NUMA-aware, we can go with *any* Redistributor/CPU.

This makes zero sense. From the point of view of a device, all the RDs
should be reachable, and firmware has no say in it. Dealing with
interrupt affinity is the responsibility of the endpoint driver, and
NUMA affinity is only a performance optimisation.

> Is there any additional information we would be able to gather from ACPI
> or DT that's not there currently, that would be useful here?

You will need some firmware information describing that a given set of
devices must use the RDs for their MSIs. Just like we currently
describe it in IORT for the ITS. You cannot /assume/ things. At the
moment, there is nothing at all, because no-one (including Microsoft)
thought it would be a good idea not to have an ITS, which is also why
ACPI doesn't describe MBIs as a potential MSI provider.

> The other question is, what DT property can be used to instantiate the
> PCI-MSI IRQ domain for Direct LPI? As per the DT spec, there is only
> 'msi-controller' Sub-node for the ITS. 

Read again. We already a msi-controller property in the main GICv3
node for the purpose of MBIs. You can reuse this property, but you
will have to discriminate whether you want MBIs or DirectLPIs with
some extra property.

	M.

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

  reply	other threads:[~2021-07-31  9:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-08 19:36 [RFC 1/1] irqchip/gic-v3-its: Add irq domain and chip for Direct LPI without ITS Sunil Muthuswamy
2021-07-11 11:09 ` Marc Zyngier
2021-07-26 15:33   ` [EXTERNAL] " Sunil Muthuswamy
2021-07-31  9:52     ` Marc Zyngier [this message]
2021-08-03  2:11       ` Sunil Muthuswamy
2021-08-03  8:35         ` Robin Murphy
2021-08-04  9:21           ` Marc Zyngier
2021-08-04 20:10             ` Sunil Muthuswamy
2021-08-05  8:35               ` Marc Zyngier
2021-08-06 19:14                 ` Sunil Muthuswamy
2021-08-08 10:19                   ` Marc Zyngier
2021-08-09  2:35                     ` Sunil Muthuswamy
2021-08-09  9:15                       ` Marc Zyngier
2021-08-10  1:10                         ` Sunil Muthuswamy
2021-08-10 13:57                           ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tuka24kj.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Boqun.Feng@microsoft.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=kys@microsoft.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikelley@microsoft.com \
    --cc=sunilmut@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).