On 28.11.23 17:11, Roger Pau Monné wrote:
On Tue, Nov 28, 2023 at 03:42:31PM +0100, Juergen Gross wrote: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.I'm kind of lost, this translation function is specifically needed for PVH which doesn't use the Xen specific variant of acpi_register_gsi(), and hence the IRQ <-> GSI relation is whatever the Linux kernel does on native. I do understand that on a PV dom0 the proposed sysfs gsi node would match the irq node, but that doesn't seem like an issue to me. Note also that PVH doesn't use acpi_register_gsi_xen_hvm() because XENFEAT_hvm_pirqs feature is not exposed to PVH, so I expect it uses the x86 acpi_register_gsi_ioapic().
Oh, I wasn't aware of this. Sorry for the noise. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
