[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |