On Fri, Aug 05, 2011 at 09:10:09AM -0600, Alex Williamson wrote: > On Fri, 2011-08-05 at 20:42 +1000, Benjamin Herrenschmidt wrote: > > Right. In fact to try to clarify the problem for everybody, I think we > > can distinguish two different classes of "constraints" that can > > influence the grouping of devices: > > > > 1- Hard constraints. These are typically devices using the same RID or > > where the RID cannot be reliably guaranteed (the later is the case with > > some PCIe-PCIX bridges which will take ownership of "some" transactions > > such as split but not all). Devices like that must be in the same > > domain. This is where PowerPC adds to what x86 does today the concept > > that the domains are pre-existing, since we use the RID for error > > isolation & MMIO segmenting as well. so we need to create those domains > > at boot time. > > > > 2- Softer constraints. Those constraints derive from the fact that not > > applying them risks enabling the guest to create side effects outside of > > its "sandbox". To some extent, there can be "degrees" of badness between > > the various things that can cause such constraints. Examples are shared > > LSIs (since trusting DisINTx can be chancy, see earlier discussions), > > potentially any set of functions in the same device can be problematic > > due to the possibility to get backdoor access to the BARs etc... > > This is what I've been trying to get to, hardware constraints vs system > policy constraints. > > > Now, what I derive from the discussion we've had so far, is that we need > > to find a proper fix for #1, but Alex and Avi seem to prefer that #2 > > remains a matter of libvirt/user doing the right thing (basically > > keeping a loaded gun aimed at the user's foot with a very very very > > sweet trigger but heh, let's not start a flamewar here :-) > > Doesn't your own uncertainty of whether or not to allow this lead to the > same conclusion, that it belongs in userspace policy? I don't think we > want to make white lists of which devices we trust to do DisINTx > correctly part of the kernel interface, do we? Thanks, Yes, but the overall point is that both the hard and soft constraints are much easier to handle if a group or iommu domain or whatever is a persistent entity that can be set up once-per-boot by the admin with whatever degree of safety they want, rather than a transient entity tied to an fd's lifetime, which must be set up correctly, every time, by the thing establishing it. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -- 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
