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

[David Gibson]

On Mon, Sep 26, 2011 at 12:04:47PM +0200, Alexander Graf wrote:
> Am 26.09.2011 um 09:51 schrieb David Gibson <address@hidden>:
[snip]
> > 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.
> > 
> > _At least_ for PCI, I think the original VFIO layout of each BAR at a
> > fixed, well known offset is much better.  Despite its limitations,
> > just advertising a "device type" ID which describes one of a few fixed
> > layouts would be preferable to this.  I'm still hoping, that we can do
> > a bit better than that.  But we should try really hard to at the very
> > least force the metadata into a simple array of resources each with a
> > fixed size record describing it, even if it means some space wastage
> > with occasionally-used fields.  Anything more complex than that and
> > userspace is just never going to use it properly.
> 
> We will have 2 different types of user space. One wants to be as
> generic as possible and needs all this dynamic information. QEMU
> would fall into this category.
> 
> The other one is device specific drivers in user space. Here
> hardcoding might make sense.
> 
> For the generic interface, we need something that us as verbose as
> possible and lets us enumerate all the device properties, so we can
> properly map and forward them to the guest.
> 
> However, nothing keeps us from mapping BARs always at static offsets
> into the file. If you don't need the generic info, then you don't
> need it.

This sounds dangerous to me.  I can just see some future kernel hacker
going "heey, Ican rearrange these, their locations are all advertised,
right".

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson