On Thu, 15 Mar 2018 15:06:38 +0000 Daniel P. Berrangé <berrange@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
