[libvirt] [RFC PATCH 00/28] Enable multifunction pci hotplug

[Alex Williamson]

On Thu, 15 Mar 2018 15:06:38 +0000
Daniel P. Berrangé <berrange at redhat.com> wrote:
> On Thu, Mar 15, 2018 at 08:59:41AM -0600, Alex Williamson wrote:
> > 
> > Neither really bothers me, but I'm confused by the claimed existing
> > handling of SR-IOV.  Either you're assigning a PF and SR-IOV is
> > irrelevant and unavailable to the guest or you're assigning a VF and,
> > well, SR-IOV is still mostly irrelevant to libvirt unless someone
> > decides to assign the PF hosting the VF or libvirt needs to do VF
> > configuration via the PF.  Thanks,  
> 
> Hmm, could be a mis-understanding then. I was under the belief that
> when you assign the PF or a SRIOV device to the guest, all the
> VFs obviously disappear from the host due to driver being unloaded.
> The guest now has the PF, and would have the option to enable VFs
> too if it so desired, just as the host had option for when it owned
> the PF.

Yeah, that's not how it currently works.  Some people would like it if
this were the case, but we've not gotten past the security issues.  If
the user is allowed to enable SR-IOV, those VFs don't just appear for
the VM, they appear on the host.  The host needs to probe for them,
assign resources, and attach drivers.  What should the host do with VFs
that are managed by an untrusted userspace driver?  The isolation
between VFs and PFs depends on the vendor's SR-IOV implementation.
Minimally, the PF driver manages the PCI bus master config bit and can
trivially introduce a denial of service for the VFs.  Allowing a VM to
enable SR-IOV only for the purpose of assigning those VFs back to the VM
owning the PF doesn't seem to be a particularly compelling feature on
its own.  Thanks,

Alex