[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xl/SR-IOV: disposition of VFs when PF disappears?



On Mon, Oct 27, 2014 at 12:57:46PM +0000, Ian Campbell wrote:
> On Mon, 2014-10-27 at 12:36 +0000, Jan Beulich wrote:
> > All,
> > 
> > Intel reports that the sequence
> > 
> > - xl pci-assignable-add <VF>
> > - briefly run guest using that device [not sure whether that's really a
> >   necessary step]
> > - xl pci-assignable-add <PF of VF>
> > 
> > results in both VF and PF being listed as assignable (the fact that as a
> > result the PF handed to a guest doesn't work is secondary here, as I
> > think this is a driver issue). Is that really how it should be? Shouldn't
> > instead all VFs get removed when the PF device (e.g. due to the
> > PF driver getting unloaded, which is a necessary part of making it
> > assignable) goes away? Or is it required for the admin to manually
> > remove the assignable VFs prior to making the PF go away?

I am not sure I see the problem. If the user wishes to give the PF and
VF to a guest they should be able to do so?

> 
> xl is just controlling/exposing the set of devices which are bound to
> pciback here. (pci-assignable-list is literally a readdir loop over the
> relevant sysfs dir).
> 
> I'm not sure if it should be up to (lib)xl, pciback or the core Linux
> pci stuff to handle the creation/destruction of VF devices when the PF
> driver is unbound/assigned. In fact I'm not even sure if VF lifetime is
> in any way tied to the PF driver state.

It is. When we detect that the device is a VF we set some flag so that the
PF won't try to de-allocate the VFs.

> 
> I've added Konrad for a kernel-size pciback perspective.
> 
> Ian.
> 

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.