[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Scott Wood
Subject: Re: [Qemu-devel] RFC [v2]: vfio / device assignment -- layout of device fd files
Date: Mon, 26 Sep 2011 19:25:16 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]