Re: [Xen-devel] SRIOV VF reset problems

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.10.17 at 16:00, <Paul.Durrant@xxxxxxxxxx> wrote:
> I'm currently looking at a problem with a pass-through SR-IOV device where 
> the guest driver triggers a VF reset via a back-door interface to the PF. The 
> reset completes successfully but, in this scenario, it is up to the PF driver 
> running in dom0 to restore the VF's config space. This is done by simply 
> writing the bytes of config space saved prior to the reset (which may or may 
> not be against the PCI spec) but causes a particular problem with MSI...
> 
> Because Xen has code to intercept writes to the capability, and vetoes any 
> writes other than those which go to the MSI control register or the mask, the 
> PF driver cannot restore the content MSI address register(s) after the reset. 
> So, the question is how best to deal with this issue? For the moment I have a 
> hack in place which calls pci_restore_msi_state() if an attempt is made to 
> write the address which seems to work around the problem for me, but does not 
> exactly seem like a proper solution. Thoughts anyone?

Using pci_restore_msi_state() for this is probably a reasonable
approach considering the odd behavior (I generally consider it
wrong for Dom0 to do anything with the config space of a device
in use by a guest, but one might argue that here the guest is
sort of aware, and it's hence at least not "behind its back").

What I'd like to see change though is the trigger pattern - merely
checking for address writes seems too weak. I would try to make
this as tight a condition as possible, so ideally you'd watch for the
entire config space being written sequentially, and trigger the
function call after the last (conventional) word was written.
Question of course if whether the driver tries to avoid r/o fields
or anything else it considers "special".

Jan


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