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

2011-08-29 Thread Scott Wood
On 08/29/2011 02:04 PM, Anthony Liguori wrote:
> On 08/29/2011 11:51 AM, Yoder Stuart-B08248 wrote:
>> 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?

This is more extensible than a struct -- both in features, and in the
number of each type of resource that you can have, length of strings you
can have, etc.

> 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.

There's no intent to replicate config space in general -- config space
is provided as-is.  There's little overlap between config space and the
extra information provided.  Length can be had from config space, but
only by modifying it.  Physical address sort-of overlaps, though bus
addresess could be different from CPU physical addresses[1].  In both
cases, it'd be nice to stay consistent with device-tree regions.

"BAR type" is overlap, but doesn't seem too unreasonable to me.

-Scott

[1] The user is probably less likely to care about the physical address
at all in the PCI case, but consistency is nice.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2011-08-29 Thread Anthony Liguori

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html