LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Marc Zyngier <email@example.com>
To: Sunil Muthuswamy <firstname.lastname@example.org>
Cc: Robin Murphy <email@example.com>,
Thomas Gleixner <firstname.lastname@example.org>,
Michael Kelley <email@example.com>,
Boqun Feng <Boqun.Feng@microsoft.com>,
KY Srinivasan <firstname.lastname@example.org>, Arnd Bergmann <email@example.com>,
Lorenzo Pieralisi <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: Sun, 08 Aug 2021 11:19:09 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On Fri, 06 Aug 2021 20:14:13 +0100,
Sunil Muthuswamy <firstname.lastname@example.org> wrote:
> On Thursday, August 5, 2021 1:35 AM,
> Marc Zyngier <email@example.com> wrote:
> > > Hey Mark
> > I assume this is for me?
> Yes, sorry.
> > > would you be willing to consider a scoped down implementation of GIC
> > > Direct LPI with just an IRQ chip implementation and no Direct LPI
> > > PCI-MSI IRQ chip.
> > Could you please clarify? If you are not implementing MSIs, how can a
> > device signal LPIs? At the end of the day, something has to write into
> > the RD, and it isn't going to happen by sheer magic.
> > > This will allow a MSI provider (such as Hyper-V vPCI) to provide a
> > > PCI-MSI IRQ chip on top of the Direct LPI IRQ chip and enable
> > > PCI-MSI scenarios, and avoid building in assumptions in other cases
> > > (like PCI) where firmware specification is not available.
> > I really don't get what you are suggesting. Could you please describe
> > what you have in mind?
> The suggestion was to *not* implement the PCI-MSI IRQ chip in the
> Direct LPI GIC implementation, but let the endpoint/specific
> implementation provide for the MSI IRQ chip.
> For example, the Hyper-V vPCI module does implement a PCI-MSI IRQ
> chip (refer to 'hv_pcie_init_irq_domain'). Microsoft Hypervisor
> provides/virtualizes the MSI address to be used for Hyper-V vPCI. The
> Hypervisor might be using the ITS in the background, but it expects
> the device to be programmed with the MSI address that it provides.
> And, the Hypervisor takes care of routing the interrupt to the guest.
> This is done by the Hyper-V vPCI MSI IRQ chip (refer to
> hv_msi_irq_chip) compose MSI message.
> Today, for X64, Hyper-V vPCI PCI-MSI irq chip parents itself to the
> architectural 'x86_vector_domain'. The suggestion here was to see
> if we can support a similar setup for ARM, where the Hyper-V vPCI
> PCI-MSI irq chip can parent itself to the 'Direct LPI arch IRQ chip'
> (to be implemented).
> The arch Direct LPI arch IRQ chip is needed to enable LPIs, invalidate
> the LPI configuration (GICR_INVLPIR et. al. ) and allocate LPI IRQs from
> the LPI interrupt namespace (i.e. 8192-<num LPIS>).
> Happy to expand on this further, if the above is not clear.
[+Lorenzo, as he deals with both PCI and ACPI]
I think it is clear enough, but I don't see what this buys us other
than turning DirectLPI into something that is essentially private to
Hyper-V, just for the sake of sidestepping a firmware description.
Furthermore, the Hyper-V "single MSI address" model doesn't match the
way DirectLPI works (after all, this is one of the many reasons why we
have the ITS).
The architecture already gives you everything you need to make things
work in Hyper-V. You can easily implement the DirectLPI support (you
definitely need most of it anyway), and the PCI-MSI layer is
*free*. All you need is a firmware description. Which I don't believe
is the end of the world, given that DT is freely hackable and that
IORT is an ARM-private extension to ACPI. I'm sure you know who to
reach out to in order to start a draft (and if you don't, I can give
you names offline).
I am not interested in expanding the GICv3 architecture support if it
cannot be generally used in a way that is *compliant with the
architecture*. If you think DirectLPIs can make the hypervisor
simpler, I'm fine with it. But let's fully embrace the concept instead
of hiding it behind a layer of PV muck. It will even have a chance of
working on bare metal (such as on the machine that is humming behind
me, or even the Fast Model).
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2021-08-08 10:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-08 19:36 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
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 [this message]
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 \
--subject='Re: [EXTERNAL] Re: [RFC 1/1] irqchip/gic-v3-its: Add irq domain and chip for Direct LPI without ITS' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).