From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9ZPm-0005eg-Gs for qemu-devel@nongnu.org; Fri, 30 Sep 2011 05:30:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R9ZPi-0002oa-2m for qemu-devel@nongnu.org; Fri, 30 Sep 2011 05:29:54 -0400 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:35492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9ZPh-0002oD-EB for qemu-devel@nongnu.org; Fri, 30 Sep 2011 05:29:50 -0400 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp01.au.ibm.com (8.14.4/8.13.1) with ESMTP id p8U9S2YX019433 for ; Fri, 30 Sep 2011 19:28:02 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8U9TaE11474734 for ; Fri, 30 Sep 2011 19:29:36 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8U9TZBb017700 for ; Fri, 30 Sep 2011 19:29:36 +1000 Date: Fri, 30 Sep 2011 18:40:57 +1000 From: David Gibson Message-ID: <20110930084057.GE4512@yookeroo.fritz.box> References: <20110926075144.GT12286@yookeroo.fritz.box> <3D54B89C-A0A3-4461-A7A1-3F1E4AB79296@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D54B89C-A0A3-4461-A7A1-3F1E4AB79296@suse.de> Subject: Re: [Qemu-devel] RFC [v2]: vfio / device assignment -- layout of device fd files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Benjamin Herrenschmidt , "kvm@vger.kernel.org" , Stuart Yoder , "qemu-devel@nongnu.org" , "alex.williamson@redhat.com" , "avi@redhat.com" , Scott Wood On Mon, Sep 26, 2011 at 12:04:47PM +0200, Alexander Graf wrote: > Am 26.09.2011 um 09:51 schrieb David Gibson : [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