Re: [RFC XEN PATCH v2 3/3] tools: Add new function to get gsi from irq

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 28 Nov 2023, 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.

Maybe something to add to drivers/xen/sys-hypervisor.c in Linux.
Juergen what do you think?