On Mon, Apr 02, 2012 at 03:14:40PM -0600, Alex Williamson wrote: > IOMMUs often do not have visibility of individual devices in the > system. Due to IOMMU design, bus topology, or device quirks, we > can often only identify groups of devices. Examples include > Intel VT-d & AMD-Vi which often have function level visibility > compared to POWER partitionable endpoints which have bridge level > granularity. That's a significant oversimplification of the situation on POWER, although it doesn't really matter in this context. On older (i.e. pre PCI-E) hardware, PEs have either host bridge (i.e. domain) granularity, or in IIUC in some cases p2p bridge granularity, using special p2p bridges, since that's the only real way to do iommu differentiation without the PCI-E requestor IDs. This isn't as coarse as it seems in practice, because the hardware is usually built with a bridge per physical PCI slot. On newer PCI-E hardware, the PE granularity is basically a firmware decision, and can go down to function level. I believe pHyp puts the granularity at the bridge level. Our non-virtualized Linux "firmware" currently does put it at the function level, but Ben is thinking about changing that to bridge level: again, because of the hardware design that isn't as coarse as it seems, and at this level we can hardware guarantee isolation to a degree that's not possible at the function level. > PCIe-to-PCI bridges also often cloud the IOMMU > visibility as it cannot distiguish devices behind the bridge. > Devices can also sometimes hurt themselves by initiating DMA using > the wrong source ID on a multifunction PCI device. > > IOMMU groups are meant to help solve these problems and hopefully > become the working unit of the IOMMI API. So far, so simple. No objections here. I am trying to work out what the real difference in approach is in this seriers from either your or my earlier isolation group series. AFAICT it's just that this approach is explicitly only about IOMMU identity, ignoring (here) any other factors which might affect isolation. Or am I missing something? -- 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
