On 2023/11/28 22: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)? Yes, I also ever thought this way. Add a sysfs node in /sys/bus/pci/devices/xxxx:xx:xx.x/gsi. But I am not sure sysfs or privcmd, which is better. If use sysfs node, should I need to use the macro of Xen to wrap the codes? And is it suitable to create it in function acpi_register_gsi_ioapic?
> > 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. > > Thanks, Roger. -- Best regards, Jiqian Chen.
