On Thu, Jan 12, 2012 at 03:55:00PM +0100, Joerg Roedel wrote: > On Tue, Jan 10, 2012 at 11:15:54AM -0600, Stuart Yoder wrote: > > We have devices that are capable of and need to access multiple > > domains. At the hardware level the device has multiple 'logical > > I/O device numbers' which is the index into our IOMMU tables. This > > means the device can target DMA operations to 2 different > > address spaces. > > Your IOMMU is a real challenge it seems ;-) Yes. :-( > > -define a new iommu_ops function to add devices with this hardware > > domain info: > > > > extern int iommu_attach_device_ext(struct iommu_domain *domain, > > struct device *dev, void *iommu_hw_domain); > > How about just enumerating the device address spaces with an u32 and use > that to assign the domains. Or is an in-kernel descriptor for the > hardware-side really needed? If so, why? A u32 would work well enough for our hardware, which has only one numberspace for this (well, there are multiple IOMMUs, but you're supposed to treat them as if they were one and point them all to the same tables), but I'd hesitate to design the API that way -- we'd have less complexity and confusion in interrupt config if we described IRQs as pointers rather than ints, for example. Ideally the hw domain would be a pointer to a struct that contains a pointer to iommu ops, rather than tie it to what kind of bus dev sits on (that both buses are "platform" doesn't mean they're anything like each other), and dev would just be a place where you can find a list of IOMMU resources (just like IRQs, which can each map to a different hw controller). That would be a significant overhaul, though -- letting it be a void pointer would mean that bus types could choose this interpretation gradually when and if they encounter the need, without having to invent numberspace encodings or allocation. How about an opaque unsigned long, that could be an integer or a pointer? -Scott -- 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
