Am 14.11.2011 um 23:26 schrieb Scott Wood <scottw...@freescale.com>:
> On 11/14/2011 02:54 PM, Alex Williamson wrote: >> On Fri, 2011-11-11 at 18:14 -0600, Scott Wood wrote: >>> What are the semantics of "desired and/or returned dma address"? >> >> I believe the original intention was that a user could leave dmaaddr >> clear and let the iommu layer provide an iova address. The iommu api >> has since evolved and that mapping scheme really isn't present anymore. >> We'll currently fail if we can map the requested address. I'll update >> the docs to make that be the definition. > > OK... if there is any desire in the future to have the kernel pick an > address (which could be useful for IOMMUs that don't set > VFIO_IOMMU_FLAGS_MAP_ANY), there should be an explicit flag for this, > since zero could be a valid address to request (doesn't mean "clear"). > >>> Note that the "length of structure" approach means that ioctl numbers >>> will change whenever this grows -- perhaps we should avoid encoding the >>> struct size into these ioctls? >> >> How so? What's described here is effectively the base size. If we >> later add feature foo requiring additional fields, we set a flag, change >> the size, and tack those fields onto the end. The kernel side should >> balk if the size doesn't match what it expects from the flags it >> understands (which I think I probably need to be more strict about). > > The size of the struct is encoded into the ioctl number via the _IOWR() > macro. If we want the struct to be growable in the future, we should > leave that out and just use _IO(). Otherwise if the size of the struct > changes, the ioctl number changes. This is annoying for old userspace > plus new kernel (have to add compat entries to the switch), and broken > for old kernel plus new userspace. Avi wanted to write up a patch for this to allow ioctls with arbitrary size, for exctly this purpose. > >>> Can we limit the IOMMU_API dependency to the IOMMU parts of VFIO? It >>> would still be useful for devices which don't do DMA, or where we accept >>> the lack of protection/translation (e.g. we have a customer that wants >>> to do KVM device assignment on one of our lower-end chips that lacks an >>> IOMMU). >> >> Ugh. I'm not really onboard with it given that we're trying to sell >> vfio as a secure user space driver interface with iommu-based >> protection. > > That's its main use case, but it doesn't make much sense to duplicate > the non-iommu-related bits for other use cases. > > This applies at runtime too, some devices don't do DMA at all (and thus > may not be part of an IOMMU group, even if there is an IOMMU present for > other devices -- could be considered a standalone group of one device, > with a null IOMMU backend). Support for such devices can wait, but it's > good to keep the possibility in mind. I agree. Potentially backing a device with a nop iommu also makes testing easier. Alex >
