Re: [PATCH 0/1] uio_pci_generic: extensions to allow access fornon-privileged processes

[Michael S. Tsirkin]

On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
> uio_pci_generic has previously been discussed on the KVM list, but this patch 
> has nothing to do with KVM, so it is also going to LKML.
> 
> The point of this patch is to beef up the uio_pci_generic driver so that a 
> non-privileged user process can run a user level driver for most PCIe 
> devices. This can only be safe if there is an IOMMU in the system with 
> per-device domains.

Why? Per-guest domain should be safe enough.

>  Privileged users (CAP_SYS_RAWIO) are allowed if there is 
> no IOMMU.

qemu does not support it, I doubt this last option is worth having.

> Specifically, I seek to allow low-latency user level network drivers (non 
> tcp/ip) which directly access SR-IOV style virtual network adapters, for use 
> with packages such as OpenMPI.
> 
> Key areas of change:
> - ioctl extensions to allow registration and dma mapping of memory regions, 
> with lock accounting
> - support for mmu notifier driven de-mapping
> - support for MSI and MSI-X interrupts (the intel 82599 VFs support only 
> MSI-X)
> - allowing interrupt enabling and device register mapping all 
> through /dev/uio* so that  permissions may be granted just by chmod 
> on /dev/uio*

For non-priveledged users, we need a way to enforce that
device is bound to an iommu.

Further, locking really needs to be scoped with iommu domain existance
and with iommu mappings: as long as a page is mapped in iommu,
it must be locked. This patch does not seem to enforce that.

Also note that what we really want is a single iommu domain per guest,
not per device.

For this reason, I think we should address the problem somwwhat
differently:
- Create a character device to represent the iommu
- This device will handle memory locking etc
- Allow binding this device to iommu
- Allow other operations only after iommu is bound

Thanks!

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/