[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC: vfio / device assignment -- layout of device fd fi
From: |
Scott Wood |
Subject: |
Re: [Qemu-devel] RFC: vfio / device assignment -- layout of device fd files |
Date: |
Mon, 29 Aug 2011 14:32:29 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10 |
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.