Re: [Qemu-devel] RFC: vfio / device assignment -- layout of device fd files

Anthony Liguori
2011-08-29T19:04:09Z

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