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

Reply via email to