On Thu, 2012-02-02 at 12:24 +1100, David Gibson wrote: > On Wed, Feb 01, 2012 at 01:08:39PM -0700, Alex Williamson wrote: > > On Wed, 2012-02-01 at 15:46 +1100, David Gibson wrote: > > > This patch series introduces a new infrastructure to the driver core > > > for representing "device isolation groups". That is, groups of > > > devices which can be "isolated" in such a way that the rest of the > > > system can be protected from them, even in the presence of userspace > > > or a guest OS directly driving the devices. > > > > > > Isolation will typically be due to an IOMMU which can safely remap DMA > > > and interrupts coming from these devices. We need to represent whole > > > groups, rather than individual devices, because there are a number of > > > cases where the group can be isolated as a whole, but devices within > > > it cannot be safely isolated from each other - this usually occurs > > > because the IOMMU cannot reliably distinguish which device in the > > > group initiated a transaction. In other words, isolation groups > > > represent the minimum safe granularity for passthrough to guests or > > > userspace. > > > > > > This series provides the core infraustrcture for tracking isolation > > > groups, and example implementations initializing the groups > > > appropriately for two PCI bridges (which include IOMMUs) found on IBM > > > POWER systems. > > > > > > Actually using the group information is not included here, but David > > > Woodhouse has expressed an interest in using a structure like this to > > > represent operations in iommu_ops more correctly. > > > > > > Some tracking of groups is a prerequisite for safe passthrough of > > > devices to guests or userspace, such as done by VFIO. Current VFIO > > > patches use the iommu_ops->device_group mechanism for this. However, > > > that mechanism is awkward, because without an in-kernel concrete > > > representation of groups, enumerating a group requires traversing > > > every device on a given bus type. It also fails to cover some very > > > plausible IOMMU topologies, because its groups cannot span devices on > > > multiple bus types. > > > > So far so good, but there's not much meat on the bone yet. > > True.. Any update to this series? It would be great if we could map out the functionality to the point of breaking down and distributing work... or determining if the end result has any value add to what VFIO already does. 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
