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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Thursday, June 25, 2015, 1:29:39 PM, you wrote:

>>>> 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?

Normal qemu-xen,  git://xenbits.xen.org/qemu-upstream-unstable.git master

The tree has as last commit:
commit 579e90432e995d6cb6f8520aca557fa6646f94ec
Author: Petr Matousek <pmatouse@xxxxxxxxxx>
Date:   Sun May 24 10:53:44 2015 +0200


> 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.

The guest(linux) keeps running, only that terminal with the lsusb 
command hangs, so no problem to gather the lspci output.
Guest lspci -vvvknn attached.

> 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?

No those aren't new (they are present for at least some months now), something 
in a booting guest kernel triggers those, not only for HVM's  but 
also for PV guests (and so they also appear for dom0).
                  

> Jan

Attachment: guest-lspci.txt
Description: Text document

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