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<pugs@xxxxxxxxx>
---
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.
[a pony for avi...]
The major new functionality in this version is the ability to deal with
PCI config space accesses (through read& write calls) - but includes table
driven code to determine whats safe to write and what is not.
I don't really see why this is helpful: a driver written corrrectly
will not access these addresses, and we need an iommu anyway to protect
us against a drivers.
Haven't reviewed the code (yet) but things like the BARs, MSI, and
interrupt disable need to be protected from the guest regardless 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
