Re: [RFC XEN PATCH v3 2/3] x86/pvh: Add (un)map_pirq and setup_gsi for PVH dom0

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 15 Dec 2023, Roger Pau Monné wrote:
> On Fri, Dec 15, 2023 at 09:24:22AM +0100, Jan Beulich wrote:
> > On 14.12.2023 23:49, Stefano Stabellini wrote:
> > > On Thu, 14 Dec 2023, Roger Pau Monné wrote:
> > >> On Thu, Dec 14, 2023 at 10:58:24AM +0100, Jan Beulich wrote:
> > >>> On 14.12.2023 10:55, Roger Pau Monné wrote:
> > >>>> One way to bodge this would be to detect whether the caller of
> > >>>> XEN_DOMCTL_irq_permission is a PV or an HVM domain, and in case of HVM
> > >>>> assume the pirq field is a GSI.  I'm unsure however how that will work
> > >>>> with non-x86 architectures.
> > > 
> > > PIRQ is an x86-only concept. We have event channels but no PIRQs on ARM.
> > > I expect RISC-V will be the same.
> > > 
> > > 
> > >>>> It would  be better to introduce a new XEN_DOMCTL_gsi_permission, or
> > > 
> > > "GSI" is another x86-only concept.
> > 
> > Just to mention it - going through the ACPI spec, this looks to be an
> > arch-neutral ACPI term. It is also used in places which to me look
> > pretty Arm-centric.
> 
> Oh, indeed, they have retrofitted GSI(V?) for Arm also, as a way to have a
> "flat" uniform interrupt space.

Interesting, and I am not surprised. (I don't usually work with ACPI on
ARM because none of our boards come with ACPI, they are all Device
Tree.)


> So I guess Arm would also need the
> GSI type, unless the translation from GSI to SPI or whatever platform
> interrupt type is done by the guest and Xen is completely agnostic to
> GSIs (if that's even possible).

I am guessing that GSIs on ARM must be mapped 1:1 to SPIs otherwise we
would have severe inconsistencies between ACPI and DeviceTree booting
and some boards support both.

Also to answer your question about LPIs: those are MSIs on ARM.