On 28.11.23 15:25, Roger Pau Monné wrote:
On Fri, Nov 24, 2023 at 06:41:36PM +0800, Jiqian Chen wrote:In PVH dom0, it uses the linux local interrupt mechanism, when it allocs irq for a gsi, it is dynamic, and follow the principle of applying first, distributing first. And if you debug the kernel codes, you will find the irq number is alloced from small to large, but the applying gsi number is not, may gsi 38 comes before gsi 28, that causes the irq number is not equal with the gsi number. And when we passthrough a device, QEMU will use its gsi number to do mapping actions, see xen_pt_realize-> xc_physdev_map_pirq, but the gsi number is got from file /sys/bus/pci/devices/xxxx:xx:xx.x/irq in current code, so it will fail when mapping. And in current codes, there is no method to translate irq to gsi for userspace.I think it would be cleaner to just introduce a new sysfs node that contains the gsi if a device is using one (much like the irq sysfs node)? Such ioctl to translate from IRQ to GSI has nothing to do with Xen, so placing it in privcmd does seem quite strange to me. I understand that for passthrough we need the GSI, but such translation layer from IRQ to GSI is all Linux internal, and it would be much simpler to just expose the GSI in sysfs IMO.
You are aware that we have a Xen specific variant of acpi_register_gsi()? It is the Xen event channel driver being responsible for the GSI<->IRQ mapping. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
