You've convinced us that we should use separate groups. But If I do that I can't think of a clean way to force the VFs to be probed by VFIO. The ideas I have are: 1. Add a driver_override parameter to pci_enable_sriov, sriov_enable and virtfn_add. 2. Register to the bus notifier of the PF's bus before calling pci_enable_sriov and then override the Driver in BUS_NOTIFY_ADD_DEVICE event like I did in the IOMMU group notifier when the group was shared. Do you have a better idea? or a recommendation as to which of my ideas I should use? Thank, Ilya > -----Original Message----- > From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > Sent: Monday, June 13, 2016 7:01 PM > 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 > > On Mon, 13 Jun 2016 07:08:03 +0000 > Ilya Lesokhin <ilyal@xxxxxxxxxxxx> wrote: > > > > -----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? > > Sorry, I don't agree, nor do I think that nested IOMMU groups are the > solution to the problem (or even really understand what nest IOMMU > groups are). It seems we have an issue that an untrusted user is creating > devices and we're trying to overload the concept of an IOMMU group to > handle that. An IOMMU group is meant to describe the DMA isolation of a > set of devices, so it really has no business being overloaded to enforce > ownership like this, nor can we assume that we can support multiple IOMMU > contexts within a group regardless of a "real nested IOMMU". We already > see coming a very serious usage restriction that a user cannot create > independent IOMMU contexts as a direct result of this hack, which severely > limits future usefulness. I don't know what the solution is here, but I'm > pretty sure this is not it. Thanks, > > Alex -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
