On 08/29/2011 11:51 AM, Yoder Stuart-B08248 wrote:
Alex Graf, Scott Wood, and I met last week to try to flesh out
some details as to how vfio could work for non-PCI devices,
like we have in embedded systems. This most likely will
require a different kernel driver than vfio-- for now we are
calling it "dtio" (for device tree I/O) as there is no way
to discover these devices except from the device tree. But
the dtio driver would use the same architecture and interfaces
as vfio.
For devices on a system bus and represented in a device
tree we have some different requirements than PCI for what
is exposed in the device fd file. A device may have multiple
address regions, multiple interrupts, a variable length device
tree path, whether a region is mmapable, etc.
With existing vfio, the device fd file layout is something
like:
0xF Config space offset
...
0x6 ROM offset
0x5 BAR 5 offset
0x4 BAR 4 offset
0x3 BAR 3 offset
0x2 BAR 2 offset
0x1 BAR 1 offset
0x0 BAR 0 offset
We have an alternate proposal that we think is more flexible,
extensible, and will accommodate both PCI and system bus
type devices (and others).
Instead of config space fixed at 0xf, we would propose
a header and multiple 'device info' records at offset 0x0 that would
encode everything that user space needs to know about
the device:
Why not just use an ioctl with a proper struct?
The config space is weird for PCI access because it's mirroring a well
known binary blob. It's not something to replicate if you're inventing
something new.
Regards,
Anthony Liguori
--
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
