Re: [Xen-devel] pci-passthrough loses msi-x interrupts ability after domain destroy

[Jérôme Oufella <jerome.oufella@xxxxxxxxxxxxxxxxxxxx>]

Hi Jan and al,

----- On Sep 21, 2017, at 9:12 AM, Jan Beulich JBeulich@xxxxxxxx wrote:

> And did you verify that the OS actually makes an attempt to clear
> this mask-all flag? If such an attempt doesn't have the intended
> effect, finding the problem location in the code and sending a
> fix can't be that difficult. If otoh the guest doesn't do this, then
> we'd need to figure out whether we leave the device in a wrong
> state after de-assigning it from the original guest instance (albeit,
> as Roger said, the reset the device is supposed to go through
> would be expected to clear it).

> I can certainly see an OS not
> necessarily expecting the bit to be set when first gaining control
> of the device. For this, look at the lspci output for the device in
> Dom0 between shutting down and then restarting the guest.
> 
> Jan

Thanks for the good hints and reset patches.

I tried the various device reset patches posted on this discussion
(do_flr, Christopher's "more thorough" reset_device) but without luck.

After reset, I could notice that lspci shows the device's Masked
state has been cleared but a newly started guest will still fail
to receive any interrupts.

However, I just found a sequence that makes the device survive a guest
destruction: issuing a remove_slot, unbind, bind, new_slot on that
specific device in pciback's sysfs corner, then re-creating the
domain. This allows interrupts flowing back into both windows and
linux domains, without involving an additional reset step.

It's a quick fix for me, but I'm wondering what path differs between
the two methods, and how what it leads to could become part of the
standard reset path.

Regards,
Jerome

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