On Wed, Sep 11, 2024 at 02:58:32PM +0800, Jiqian Chen wrote: > When dom0 is PVH, and passthrough a device to dumU, xl will > use the gsi number of device to do a pirq mapping, see > pci_add_dm_done->xc_physdev_map_pirq, but the gsi number is > got from file /sys/bus/pci/devices/<sbdf>/irq, that confuses > irq and gsi, they are in different space and are not equal, > so it will fail when mapping. > To solve this issue, to get the real gsi and add a new function > xc_physdev_map_pirq_gsi to get a free pirq for gsi. > Note: why not use current function xc_physdev_map_pirq, because > it doesn't support to allocate a free pirq, what's more, to > prevent changing it and affecting its callers, so add > xc_physdev_map_pirq_gsi. > > Besides, PVH dom0 doesn't have PIRQs flag, it doesn't do > PHYSDEVOP_map_pirq for each gsi. So grant function callstack > pci_add_dm_done->XEN_DOMCTL_irq_permission will fail at function > domain_pirq_to_irq. And old hypercall XEN_DOMCTL_irq_permission > requires passing in pirq, it is not suitable for PVH dom0 that > doesn't have PIRQs to grant irq permission. > To solve this issue, use the another hypercall > XEN_DOMCTL_gsi_permission to grant the permission of irq( > translate from gsi) to dumU when dom0 has no PIRQs. > > Signed-off-by: Jiqian Chen <jiqian.c...@amd.com> > Signed-off-by: Huang Rui <ray.hu...@amd.com> > Signed-off-by: Chen Jiqian <jiqian.c...@amd.com>
Reviewed-by: Anthony PERARD <anthony.per...@vates.tech> Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech