On 2023/11/29 00: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(). Yes, PVH use acpi_register_gsi_ioapic, thank Roger for explanation.
> > Thanks, Roger. -- Best regards, Jiqian Chen.
