Re: [Xen-devel] Issue with MSI in a HVM domU with several passed through PCI devices

[Rolu <rolu@xxxxxxxx>]

On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 20.06.12 at 15:58, Rolu <rolu@xxxxxxxx> wrote:
>> On Tue, Jun 19, 2012 at 11:45 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> Unless this is in the guest kernel, we'll likely need a code fix here,
>>> but for determining what and where, we'd need you to provide
>>> the qemu log for the domain as well (there ought to be entries
>>> starting with "Update msi with pirq", and the gflags value is of
>>> particular interest). Depending on what we see, we may then
>>> need you to do some further debugging.
>>>
>>
>> There are, these: (I've copied the full logs below)
>>
>> pt_msi_update: Update msi with pirq 37 gvec 0 gflags 3031
>> pt_msi_update: Update msi with pirq 36 gvec 0 gflags 3030
>> pt_msi_update: Update msi with pirq 35 gvec 0 gflags 302f
>
> Okay, so at that point the bad value is already there. I'd
> suggest taking it up the usage chain, so adding some logging
> in pt_msgdata_reg_write() (where the original value -
> ptdev->msi->data - is being computed) would likely be a
> good first step.
>

This took a while as I'm not very familiar with it all yet.

The write function gets passed a *value of 0x4300 and that is also
what gets assigned to ptdev->msi->data. The delivery mode is bit 8 to
10 of that value, which is indeed 3. lspci -vvv on the domU also shows
that the MSI data field is 4300, but I suppose it just reads that back
from qemu. Anyway, this seems in order, at least as far as I can see.

> At the same time, adding logging to the guest kernel would
> be nice, to see what value it actually writes (in a current
> kernel this would be in __write_msi_msg()).
>

Turns out that msg->data here is also 0x4300, so it seems the guest
kernel is producing these values. I caused it to make a stack trace
and this pointed back to xen_hvm_setup_msi_irqs. This function uses
the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
current data field and if it isn't equal to the macro it uses
xen_msi_compose_msg to make a new message, but that function just sets
the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
then gets passed to __write_msi_msg and that's that. There are no
other writes through __write_msi_msg (except for the same thing for
other devices).

The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
decoded as the delivery mode, so it seems the kernel is intentionally
setting it to 3.

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