On Mon, 2011-08-08 at 11:28 +0300, Avi Kivity wrote: > On 08/03/2011 05:04 AM, David Gibson wrote: > > I still don't understand the distinction you're making. We're saying > > the group is "owned" by a given user or guest in the sense that no-one > > else may use anything in the group (including host drivers). At that > > point none, some or all of the devices in the group may actually be > > used by the guest. > > > > You seem to be making a distinction between "owned by" and "assigned > > to" and "used by" and I really don't see what it is. > > > > Alex (and I) think that we should work with device/function granularity, > as is common with other archs, and that the group thing is just a > constraint on which functions may be assigned where, while you think > that we should work at group granularity, with 1-function groups for > archs which don't have constraints. > > Is this an accurate way of putting it? Mostly correct, yes. x86 isn't immune to the group problem, it shows up for us any time there's a PCIe-to-PCI bridge in the device hierarchy. We lose resolution of devices behind the bridge. As you state though, I think of this as only a constraint on what we're able to do with those devices. Perhaps part of the differences is that on x86 the constraints don't really effect how we expose devices to the guest. We need to hold unused devices in the group hostage and use the same iommu domain for any devices assigned, but that's not visible to the guest. AIUI, POWER probably needs to expose the bridge (or at least an emulated bridge) to the guest, any devices in the group need to show up behind that bridge, some kind of pvDMA needs to be associated with that group, there might be MMIO segments and IOVA windows, etc. Effectively you want to transplant the entire group into the guest. Is that right? Thanks, Alex -- 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
