LKML Archive on
help / color / mirror / Atom feed
From: Marc Zyngier <>
To: Sunil Muthuswamy <>
Cc: Robin Murphy <>,
	Thomas Gleixner <>,
	"" <>,
	"" <>,
	"" <>,
	Michael Kelley <>,
	Boqun Feng <>,
	KY Srinivasan <>, Arnd Bergmann <>,
	Lorenzo Pieralisi <>
Subject: Re: [EXTERNAL] Re: [RFC 1/1] irqchip/gic-v3-its: Add irq domain and chip for Direct LPI without ITS
Date: Tue, 10 Aug 2021 14:57:06 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, 10 Aug 2021 02:10:40 +0100,
Sunil Muthuswamy <> wrote:
> On Monday, August 9, 2021 2:15 AM,
> Marc Zyngier <> wrote:
> [...]
> > If you plug directly into the GICv3 layer, I'd rather you inject SPIs,
> > just like any other non-architectural MSI controller. You can directly
> > interface with the ACPI GSI layer for that, without any need to mess
> > with the GICv3 internals. The SPI space isn't very large, but still
> > much larger than the equivalent x86 space (close to 1000).
> > 
> > If time is of the essence, I suggest you go the SPI way. For anything
> > involving LPIs, I really want to see a firmware spec that works for
> > everyone as opposed to a localised Hyper-V hack.
> > 
> Ok, thanks. Before we commit to anything, I would like to make sure
> that I am on the same page in terms of your description. With that in
> mind, I have few questions. Hopefully, these should settle the matter.
> 1. If we go with the SPI route, then the way I envision it is that the 
>     Hyper-V vPCI driver will implement an IRQ chip, which will take
>     care of allocating & managing the SPI interrupt for Hyper-V vPCI.
>     This IRQ chip will parent itself to the architectural GIC IRQ chip for
>     general interrupt management. Does that match with your
>     understanding/suggestion as well?


> 2. In the above, how will Hyper-V vPCI module discover the
>     architectural GIC IRQ domain generically for virtual devices that
>     are not firmware enumerated? Today, the GIC v3 IRQ domain is
>     not exported and the general 'irq_find_xyz' APIs only work for
>     firmware enumerated devices (i.e. something that has a fwnode
>     handle).

You don't need to discover it with ACPI. You simply instantiate your
own irqdomain using acpi_irq_create_hierarchy(), which will do the
right thing. Your PCI driver will have to create its own fwnode out of
thin air (there is an API for that), and call into this function to
plumb everything.

> 3. Longer term, if we implement LPIs (with an ITS or Direct LPI), to
>     be able to support all scenarios such as Live Migration, the
>     Hyper-V virtual PCI driver would like to be able to control the
>     MSI address & data that gets programmed on the device
>    (i.e. .irq_compose_msi_msg). We can use the architectural
>    methods for everything else. Does that fit into the realm of
>    what would be acceptable upstream?

I cannot see how this works. The address has to match that of the
virtual HW you target (whether this is a redistributor or an ITS), and
the data is only meaningful in that context. And it really shouldn't
matter at all, as I expect you don't let the guest directly write to
the PCI MSI-X table.

If you let the guest have access direct to that table (which seems to
contradict your "live migration" argument), then your best bet is to
use provide a skeletal IOMMU implementation, and get
iommu_dma_compose_msi_msg() to do the remapping. But frankly, that's
horrible and I fully expect the IOMMU people to push back (and that
still doesn't give you any control over the data, only the address).



Without deviation from the norm, progress is not possible.

      reply	other threads:[~2021-08-10 13:57 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
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 [this message]

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:

* 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).