From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy77y-0003l3-8k for qemu-devel@nongnu.org; Mon, 29 Aug 2011 15:04:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qy77x-00030D-Ar for qemu-devel@nongnu.org; Mon, 29 Aug 2011 15:04:10 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:53494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy77x-000309-6b for qemu-devel@nongnu.org; Mon, 29 Aug 2011 15:04:09 -0400 Received: by gwb19 with SMTP id 19so5759210gwb.4 for ; Mon, 29 Aug 2011 12:04:08 -0700 (PDT) Message-ID: <4E5BE2A5.7040201@codemonkey.ws> Date: Mon, 29 Aug 2011 14:04:05 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <9F6FE96B71CF29479FF1CDC8046E15031B3313@039-SN1MPN1-002.039d.mgd.msft.net> In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E15031B3313@039-SN1MPN1-002.039d.mgd.msft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: vfio / device assignment -- layout of device fd files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yoder Stuart-B08248 Cc: Wood Scott-B07421 , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , Alexander Graf , "alex.williamson@redhat.com" , "avi@redhat.com" , "Joerg.Roedel@amd.com" , David Gibson On 08/29/2011 11:51 AM, Yoder Stuart-B08248 wrote: > Alex Graf, Scott Wood, and I met last week to try to flesh out > some details as to how vfio could work for non-PCI devices, > like we have in embedded systems. This most likely will > require a different kernel driver than vfio-- for now we are > calling it "dtio" (for device tree I/O) as there is no way > to discover these devices except from the device tree. But > the dtio driver would use the same architecture and interfaces > as vfio. > > For devices on a system bus and represented in a device > tree we have some different requirements than PCI for what > is exposed in the device fd file. A device may have multiple > address regions, multiple interrupts, a variable length device > tree path, whether a region is mmapable, etc. > > With existing vfio, the device fd file layout is something > like: > 0xF Config space offset > ... > 0x6 ROM offset > 0x5 BAR 5 offset > 0x4 BAR 4 offset > 0x3 BAR 3 offset > 0x2 BAR 2 offset > 0x1 BAR 1 offset > 0x0 BAR 0 offset > > We have an alternate proposal that we think is more flexible, > extensible, and will accommodate both PCI and system bus > type devices (and others). > > Instead of config space fixed at 0xf, we would propose > a header and multiple 'device info' records at offset 0x0 that would > encode everything that user space needs to know about > the device: Why not just use an ioctl with a proper struct? The config space is weird for PCI access because it's mirroring a well known binary blob. It's not something to replicate if you're inventing something new. Regards, Anthony Liguori