[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Issue with MSI in a HVM domU with several passed through PCI devices
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
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