LKML Archive on
help / color / mirror / Atom feed
From: Sunil Muthuswamy <>
To: Marc Zyngier <>
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 01:10:40 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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?


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

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