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 toIMO this was because this driver does two things: programming iommu and
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.
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.
[a pony for avi...]I don't really see why this is helpful: a driver written corrrectly
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.
will not access these addresses, and we need an iommu anyway to protect
us against a drivers.