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

[Juergen Gross <jgross@xxxxxxxx>]

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

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature