[Pkg-xen-devel] Bug#810379: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices

Sat Jan 30 02:13:49 UTC 2016

On Wed, Jan 27, 2016 at 01:30:05PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Jan 23, 2016 at 05:12:04PM +0100, Tommi Airikka wrote:
> > Xen developers,
> > 
> > After an upgrade of my Debian Jessie dom0 and domUs, my passthroughed
> > NIC stopped working.

I have very similar (the same?) problem with USB 3.0 controller. But on
different software versions.

> > This bug was probably introduced in Debian Jessie sometime
> > between 2015-12-30 and 2016-01-08 as 2015-12-30 as 2015-12-30 was the
> > last time I upgraded without any problems according to my dpkg.log.
> 
> This upgrade looks to only have upgraded the hypervisor?
> 
> As in I see:
> 
> domU "bug" "uname -a":
> Linux bug 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02)
> x86_64 GNU/Linux
> 
> domU "working" "uname -a":
> Linux working 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2
> (2016-01-02) x86_64 GNU/Linux
> 
> So same version? What was the earlier version of the hypervisor?

In my case, domU Linux version is 4.1.13, Xen is 4.6.0. On this versions
problem occurs. Not sure what was working version, but I guess it was
Xen 4.4.3 and Linux 3.18.something.

> The Xen version you have says:
> > (XEN) I/O virtualisation disabled
> 
> Which is not very healthy for PCI passthrough. Albeit you can do
> it with PV without IOMMU. Did the previous version of Xen have the same
> message?

In my case IOMMU is enabled.

> Looking at the code (in Linux) I see:
>  516         /* NB. We are happy to share unless we are probing. */
>  517         bind_pirq.flags = info->u.pirq.flags & PIRQ_SHAREABLE ?
>  518                                         BIND_PIRQ__WILL_SHARE : 0;
>  519         rc = HYPERVISOR_event_channel_op(EVTCHNOP_bind_pirq, &bind_pirq);
>  520         if (rc != 0) {
>  521                 pr_warn("Failed to obtain physical IRQ %d\n", irq);
>  522                 return 0;
>  523         }
> 
> It would be nice if I we had included the return code :-(

I've added a logging here and got -22 (EINVAL). Exact messages are:
[    2.656966] pcifront pci-0: Installing PCI frontend
[    2.662274] pcifront pci-0: Creating PCI Frontend Bus 0000:00
[    2.662348] pcifront pci-0: PCI host bridge to bus 0000:00
[    2.662359] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    2.662366] pci_bus 0000:00: root bus resource [mem
0x00000000-0xfffffffff]
[    2.662374] pci_bus 0000:00: root bus resource [bus 00-ff]
[    2.662917] pci 0000:00:00.0: [1912:0015] type 00 class 0x0c0330
[    2.663769] pci 0000:00:00.0: reg 0x10: [mem 0xe2200000-0xe2201fff
64bit]
[    2.688410] pcifront pci-0: claiming resource 0000:00:00.0/0
[    2.688731] pci 0000:00:00.0: Xen PCI mapped GSI18 to IRQ51
[    2.768482] alg: No test for crc32 (crc32-pclmul)
[    2.824225] xen:events: xen_bind_pirq_gsi_to_irq: returning irq 51
for gsi 18
[    2.824241] xhci_hcd 0000:00:00.0: Xen PCI mapped GSI18 to IRQ51
[    2.824713] xhci_hcd 0000:00:00.0: xHCI Host Controller
[    2.825508] xhci_hcd 0000:00:00.0: new USB bus registered, assigned
bus number 2
[    2.832356] xhci_hcd 0000:00:00.0: hcc params 0x014051cf hci version
0x100 quirks 0x00000090
[    2.836735] xen:events: Failed to obtain physical IRQ 57 (error -22)
[    2.836758] xen:events: Failed to obtain physical IRQ 58 (error -22)
[    2.836769] xen:events: Failed to obtain physical IRQ 59 (error -22)
[    2.836780] xen:events: Failed to obtain physical IRQ 60 (error -22)
[    2.836793] xen:events: Failed to obtain physical IRQ 61 (error -22)

There is a check:
 463     if ( (pirq < 0) || (pirq >= d->nr_pirqs) )
 464         return -EINVAL;

But there is also a call to pirq_guest_bind, which could return EINVAL.

> Anyhow for PV guests in the hypervisor there is a check:
>  414     if ( !is_hvm_domain(d) && !pirq_access_permitted(d, pirq) )
>  415         return -EPERM;
>  416 
> 
> And I wonder if the XEN_DOMCTL_irq_permission aka, xc_domain_irq_permission
> had been called. I remember that at some point we missed it for Xend..
> 
> Could you enable Xend debugging (if you are using that):
> 
> export XEND_DEBUG=1
> /etc/init.d/xend start
> 
> And try starting the guest. Then grep in /var/log/xen/xend.log for
> "pci: enabling irq "
> 
> You should see 18, 17 and 21.
> 
> Also if you do 'xl debug-keys i && xl dmesg'
> 
> You should see that the IRQ 17, 18, 21 are assigned to the domain.
> ?

I can't see anything like that there. The highest IRQ there is 36. Does
it mean it is some bug in xhci driver?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20160130/96b52c93/attachment.sig>