Re: [Xen-devel] SRIOV VF reset problems

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 05 October 2017 17:02
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel (xen-devel@xxxxxxxxxxxxxxxxxxxx) <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] SRIOV VF reset problems
> 
> >>> 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".

I don't believe it does but I'd have to check again... IIRC it simply 
byte-writes the base config space and then does the same for capabilities it 
knows it needs to restore.
Thanks... I'll try to narrow it down as much as I can.

  Paul

> 
> Jan


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