LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Marc Zyngier <firstname.lastname@example.org> To: Sunil Muthuswamy <email@example.com> Cc: Robin Murphy <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <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>, Lorenzo Pieralisi <email@example.com> Subject: Re: [EXTERNAL] Re: [RFC 1/1] irqchip/gic-v3-its: Add irq domain and chip for Direct LPI without ITS Date: Mon, 09 Aug 2021 10:15:15 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <MW4PR21MB200286E2CF4DA229D7059598C0F69@MW4PR21MB2002.namprd21.prod.outlook.com> On Mon, 09 Aug 2021 03:35:05 +0100, Sunil Muthuswamy <email@example.com> wrote: > > Sunday, August 8, 2021 3:19 AM, > Marc Zyngier <firstname.lastname@example.org> wrote: > > > > [+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). > > > That sounds reasonable. The DT extension here alone wont suffice for > Hyper-V and we would need the ACPI IORT extension here as well. Our > general experience with ACPI extension is that they can take time. But, > I am curious to hear from Lorenzo on his thoughts here and if just an > IORT extension means anything else in terms of timelines. > > > 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). > > > Appreciate your inputs. Since we are discussing options, there is one more > option to enable Hyper-V virtual PCI for ARM64 that I do would like to > discuss. That option is to implement the IRQ chip completely within the > Hyper-V module itself. That IRQ chip will take care of allocating LPI vectors, > enabling the interrupt (unmask, mask etc..). It won't be a Direct LPI based, > but based on custom Hyper-V methods. That chip will parent itself to the > GIC v3 IRQ domain. The only extra thing needed for this is for the Hyper-V > IRQ chip to be able to discover the GIC v3 IRQ domain, for which it > cannot use the 'irq_find_matching_fwnode' method as Hyper-V virtual > PCI bus/devices are not firmware enumerated. I am not sure if there is any > other way to discover the GIC (DOMAIN_BUS_WIRED) domain. > > What are your thoughts/feedback on the above? This will allow us to > enable the scenario for the business timelines we are targeting for, while > we wait for firmware spec updates. Long term we also want to use > architectural methods here as that helps the Hypervisor as well, and I > would be glad to pursue the firmware spec updates in parallel. This feels like yet another layer of PV ugliness that has the side effect of fragmenting the architectural support. 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. Thanks, M. -- Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2021-08-09 9:15 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 [this message] 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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=Boqun.Feng@microsoft.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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: linkBe 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).