On 05/30/2010 03:49 PM, Michael S. Tsirkin wrote:
On Sun, May 30, 2010 at 03:27:05PM +0300, Avi Kivity wrote:
On 05/30/2010 03:19 PM, Michael S. Tsirkin wrote:
On Fri, May 28, 2010 at 04:07:38PM -0700, Tom Lyon wrote:
The VFIO "driver" is used to allow privileged AND non-privileged processes to
implement user-level device drivers for any well-behaved PCI, PCI-X, and PCIe
devices.
Signed-off-by: Tom Lyon<p...@cisco.com>
---
This patch is the evolution of code which was first proposed as a patch to
uio/uio_pci_generic, then as a more generic uio patch. Now it is taken entirely
out of the uio framework, and things seem much cleaner. Of course, there is
a lot of functional overlap with uio, but the previous version just seemed
like a giant mode switch in the uio code that did not lead to clarity for
either the new or old code.
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.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
