On Fri, Aug 02, 2024 at 11:40:53AM +0200, Jan Beulich wrote: > On 02.08.2024 10:08, Roger Pau Monné wrote: > > On Mon, Jul 08, 2024 at 07:41:21PM +0800, Jiqian Chen wrote: > >> Some type of domains don't have PIRQs, like PVH, it doesn't do > >> PHYSDEVOP_map_pirq for each gsi. When passthrough a device > >> to guest base on PVH dom0, callstack > >> pci_add_dm_done->XEN_DOMCTL_irq_permission will fail at function > >> domain_pirq_to_irq, because PVH has no mapping of gsi, pirq and > >> irq on Xen side. > >> What's more, current hypercall XEN_DOMCTL_irq_permission requires > >> passing in pirq to set the access of irq, it is not suitable for > >> dom0 that doesn't have PIRQs. > >> > >> So, add a new hypercall XEN_DOMCTL_gsi_permission to grant/deny > >> the permission of irq(translate from x86 gsi) to dumU when dom0 > >> has no PIRQs. > > > > I've been wondering about this, and if the hypercall is strictly to > > resolve GSIs into IRQs, isn't that the case that Xen identity maps GSI > > into the IRQ space, and hence no translation is required? > > It was a long-winded discussion to clarify that in obscure cases > translation is required: Whenever there's a source override in ACPI.
Right, I see it's a bit convoluted to get the overrides, as those are indexed by IO-APIC pin, so we need to resolve the GSI -> (ioapic, pin) first and then check for any possible overrides. Might be helpful to mention in the commit description that the GSI to IRQ translation is done to account for ACPI overrides, as otherwise GSIs are identity mapped into IRQs. Thanks, Roger.
