From: Robin Murphy <firstname.lastname@example.org>
To: Sunil Muthuswamy <email@example.com>, Marc Zyngier <firstname.lastname@example.org>
Cc: Thomas Gleixner <email@example.com>,
Michael Kelley <firstname.lastname@example.org>,
Boqun Feng <Boqun.Feng@microsoft.com>,
KY Srinivasan <email@example.com>, Arnd Bergmann <firstname.lastname@example.org>
Subject: Re: [EXTERNAL] Re: [RFC 1/1] irqchip/gic-v3-its: Add irq domain and chip for Direct LPI without ITS
Date: Tue, 3 Aug 2021 09:35:12 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On 2021-08-03 03:11, Sunil Muthuswamy wrote:
> On Saturday, July 31, 2021 2:52 AM,
> Marc Zyngier <firstname.lastname@example.org> 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.
>>> 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.
> I am a little bit confused by your above comment. Maybe you can help me
> understand the ask. You indicate that from the point of the view of the
> device, all the RDs should be reachable. But, then if we define a mapping
> between PCI endpoint and RD in the firmware, we would be doing exactly
> the opposite. i.e. restricting the RDs that are reachable by the device. Can
> you please clarify?
> Is your concern that the device should be able to only DMA to a subset of
> GIC Redistributor, for the MSIs? If so, in the IORT, there is "memory address
> size limit" for both device and root complex nodes. In the implementation,
> we can enforce that the GICR is within that range. And, if a device deviates
> further than that (ex: by having accessibility gaps within the GICR range),
> then that is out of scope for support.
No, please don't try to abuse the Memory Address Size Limit - that has
far more chance of adversely affecting normal DMA operation than of
being any use here.
I believe the point Marc was trying to make is that firmware should not
associate a device with any one *specific* redistributor, however ACPI
currently has no way to describe that MSIs can target redistributors *at
all*, only ITS groups - there is no such concept as a "redistributor group".
next prev parent reply other threads:[~2021-08-03 8:35 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
2021-08-03 2:11 ` Sunil Muthuswamy
2021-08-03 8:35 ` Robin Murphy [this message]
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).