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

[Anirban Chakraborty <abchak@xxxxxxxxxxx>]

On 10/27/14, 6:35 AM, "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx>
wrote:

>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?

Theoretically, yes a guest can have a PF and all its VFs. However, from
security perspective PF having the privilege of resetting the device etc.,
should stay in a privileged domain. Most of the NICs have some sort of
PF-VF communication where the PF driver would ensure that VF drivers are
notified of imminent PF removal so that the VF drivers can prepare for a
graceful halt of IO. Ideally, a PF removal should do a hot unplug of the
VFs from the guests and admin should not have to manually remove them.

Anirban
 
>
>> 
>> 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


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