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, 2:40:18 PM, you wrote:

>>>> On 25.06.15 at 14:02, <linux@xxxxxxxxxxxxxx> wrote:
>> Thursday, June 25, 2015, 1:29:39 PM, you wrote:
>>> 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.

> Hmm, no, this

>         Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
>                 Vector table: BAR=0 offset=00001000
>                 PBA: BAR=0 offset=00001080

> isn't enough. I was sure I saw lspci capable of listing the individual
> table entries...

It seems to be the most verbose option for my lspci of debian Jessie.
So probably a debug-patch would be best ?

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

> No, the Dom0 ones were different from what I recall.
I will double check.

> Jan




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