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

[Anthony Liguori <anthony@codemonkey.ws>]

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