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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/10/14 12:36, 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?

Which type of devices are these?

From my recollection using igb and ixgbe with Netscalar, the VFs are
created after the PF driver has bound and started up.

Moving the binding from the real PF driver to pciback should remove the
VFs, although I would not be surprised if this has been overlooked, or
is expected to work but currently buggy.

As a logical consequence of the above, a PF with VFs must strictly not
be assignable, for safety reasons.

There are security considerations involved with passing a PF to a
domain, as that domU can still cause VFs to appear in dom0.  A PF should
either stay in dom0, be given to a trusted device driver domain.

~Andrew


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