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

[Scott Wood <scottwood@freescale.com>]

On 09/26/2011 02:57 PM, Stuart Yoder wrote:
> On Mon, Sep 26, 2011 at 2:51 AM, David Gibson
>> Um, not to put too fine a point on it, this is madness.
>>
>> Yes, it's very flexible and can thereby cover a very wide range of
>> cases.  But it's much, much too complex.  Userspace has to parse a
>> complex, multilayered data structure, with variable length elements
>> just to get an address at which to do IO.  I can pretty much guarantee
>> that if we went with this, most userspace programs using this
>> interface would just ignore this metadata and directly map the
>> offsets at which they happen to know the kernel will put things for
>> the type of device they care about.

Then they deserve to break when those offsets change, just like with all
the other bad assumptions poorly written code tends to make.

Really, it should not be that hard to parse this.  A loop with a switch
statement for toplevel records, and another loop with a switch statement
for each context in which subrecords can appear.

>> _At least_ for PCI, I think the original VFIO layout of each BAR at a
>> fixed, well known offset is much better.

This is what grew out of attempting to address the needs of assigning
non-PCI devices based on the device tree.  Personally, I'd rather be
dealing with this for PCI devices as well.

>>  Despite its limitations,
>> just advertising a "device type" ID which describes one of a few fixed
>> layouts would be preferable to this.

That's already more information than the original VFIO layout provided.

> So, is your issue really the variable length nature of what was
> proposed?
> 
> I don't think it would be that hard to make the different resources
> fixed length.   I think we have 2 types of resources now-- address
> regions and interrupts.
> 
> The only thing that get's a bit tricky is device tree paths, which
> are obviously variable length.
> 
> We could put a description of all the resources in an array with
> each element being something like 4KB??

I'm not sure what that would improve.  If the user wants to put a limit
on the size of a certain field it's willing to handle, so be it.  It'll
break in the same set of cases that would be unexpressable with such a
limitation in the interface, except that since the breakage is not in
the interface, it's more easily fixable.

-Scott