Re: [Xen-devel] Xen-unstable: pci-passthrough of device using MSI-X interrupts not working after commit x86/MSI: track host and guest masking separately

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.06.15 at 12:51, <linux@xxxxxxxxxxxxxx> wrote:
> Attached is the xl-dmesg output of:
> 
> - debug-keys M and i before guest boot
> - guest boot
> - debug-keys M and i after lsusb in the guest that hangs.

Interesting:

(XEN) [2015-06-25 10:46:31.820]  MSI-X   84 vec=aa lowest  edge   assert  log 
lowest dest=00000002 mask=1/ G/1
(XEN) [2015-06-25 10:46:31.820]  MSI-X   85 vec=b2 lowest  edge   assert  log 
lowest dest=00000002 mask=1/ G/1
(XEN) [2015-06-25 10:46:31.820]  MSI-X   86 vec=ba lowest  edge   assert  log 
lowest dest=00000002 mask=1/ G/1
(XEN) [2015-06-25 10:46:31.820]  MSI-X   87 vec=c2 lowest  edge   assert  log 
lowest dest=00000002 mask=1/ G/1
(XEN) [2015-06-25 10:46:31.820]  MSI-X   88 vec=ca lowest  edge   assert  log 
lowest dest=00000002 mask=1/ G/1

I.e. they didn't get unmasked by the guest. Is that with one of our
two qemu-s, or some other version?

I'd be curious what the guest view of the MSI-X table entries is at
that point. Can you still use the console inside the guest? If so,
sufficiently verbose lspci of the device should be able to tell us
(hoping that this isn't a Windows guest), or a dd of /dev/mem at
the right offset. Perhaps there are also way to get at that from
qemu, but I do not know how.

If none of this works or provides enough insight, I guess we'd
have to instrument msixtbl_write() to monitor guest writes to the
mask bit. (After all that's the only place the guest_masked bit
gets driven from right now.)

> The not working controller is 0000:08:00.0.

That information would have been useful only together with P
output, but since there were no MSI-X entries before the guest
started, it was pretty clear that all of them belong to the device(s)
handed to it.

Btw., are

(XEN) [2015-06-25 10:44:26.550] traps.c:3227: GPF (0000): ffff82d0801d8282 -> 
ffff82d080239eec
(XEN) [2015-06-25 10:44:26.550] traps.c:3227: GPF (0000): ffff82d0801d8282 -> 
ffff82d080239eec
(XEN) [2015-06-25 10:44:26.550] traps.c:3227: GPF (0000): ffff82d0801d8282 -> 
ffff82d080239eec
(XEN) [2015-06-25 10:44:26.550] traps.c:3227: GPF (0000): ffff82d0801d8282 -> 
ffff82d080239eec

new? Did you ever try to figure out what they're being caused by?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel