On Sun, May 30, 2010 at 04:13:59PM +0300, Avi Kivity wrote: > On 05/30/2010 04:03 PM, Michael S. Tsirkin wrote: >> >> >>>>>> IMO this was because this driver does two things: programming iommu and >>>>>> handling interrupts. uio does interrupt handling. >>>>>> We could have moved iommu / DMA programming to >>>>>> a separate driver, and have uio work with it. >>>>>> This would solve limitation of the current driver >>>>>> that is needs an iommu domain per device. >>>>>> >>>>>> >>>>>> >>>>> How do we enforce security then? We need to ensure that unprivileged >>>>> users can only use the device with an iommu. >>>>> >>>>> >>>> Force assigning to iommu before we allow any other operation? >>>> >>>> >>> That means the driver must be aware of the iommu. >>> >> The userspace driver? Yes. And It is a good thing to be explicit >> there anyway, since this lets userspace map a non-contigious >> virtual address list into a contiguous bus address range. >> > > No, the kernel driver. It cannot allow userspace to enable bus > mastering unless it knows the iommu is enabled for the device and remaps > dma to user pages. So what I suggested is failing any kind of access until iommu is assigned. > > -- > error compiling committee.c: too many arguments to function -- 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
