> -----Original Message----- > From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > Sent: Friday, June 10, 2016 1:21 AM > To: Ilya Lesokhin <ilyal@xxxxxxxxxxxx> > Cc: kvm@xxxxxxxxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx; bhelgaas@xxxxxxxxxx; > Noa Osherovich <noaos@xxxxxxxxxxxx>; Haggai Eran > <haggaie@xxxxxxxxxxxx>; Or Gerlitz <ogerlitz@xxxxxxxxxxxx>; Liran Liss > <liranl@xxxxxxxxxxxx> > Subject: Re: [PATCH 2/4] IOMMU: Force the VFs of an untrusted PF device to > be in the PFs IOMMU group ... > This deserves a comment in the code as well as the commit log, but more > importantly the side effect of this is that the user can't make use of separate > IOMMU domains for the PF vs the VF. I think this ends up making the entire > solution incompatible with things like vIOMMU since we really need to be > able to create separate address spaces per device to make that work. What's > the point of enabling SR-IOV from userspace if we can't do things like assign > VFs to nested guests or userspace in the guest? This is an incomplete > feature with that restriction. I agree that this is a problem and I will mention this limitation in the commit log. However to address this properly you need nested IOMMU group which don't really exist. This feature is still useful, at least for us, as you can enable sriov in a guest and work with probed VFs in the same guest. Furthermore, if you have a real nested IOMMU you should be able to do nested device assignment even though the PF and VF's belong to the same group. I think we should push this feature with the limitation and hopefully it will be addressed in the future, agree? Thanks, Ilya -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
