From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Subject: Re: [Qemu-devel] RFC [v2]: vfio / device assignment -- layout of device fd files Date: Fri, 30 Sep 2011 18:40:57 +1000 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 Cc: Stuart Yoder , "alex.williamson@redhat.com" , Scott Wood , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "avi@redhat.com" , "anthony@codemonkey.ws" , Benjamin Herrenschmidt To: Alexander Graf Return-path: Received: from e23smtp07.au.ibm.com ([202.81.31.140]:44403 "EHLO e23smtp07.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755320Ab1I3J3m (ORCPT ); Fri, 30 Sep 2011 05:29:42 -0400 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp07.au.ibm.com (8.14.4/8.13.1) with ESMTP id p8U9TbZN004647 for ; Fri, 30 Sep 2011 19:29:37 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8U9RTqc1728748 for ; Fri, 30 Sep 2011 19:27:29 +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 p8U9TZBh017700 for ; Fri, 30 Sep 2011 19:29:37 +1000 Content-Disposition: inline In-Reply-To: <3D54B89C-A0A3-4461-A7A1-3F1E4AB79296@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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