From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39306) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy7ZY-0001kr-0l for qemu-devel@nongnu.org; Mon, 29 Aug 2011 15:32:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qy7ZX-0000BA-6P for qemu-devel@nongnu.org; Mon, 29 Aug 2011 15:32:39 -0400 Received: from am1ehsobe003.messaging.microsoft.com ([213.199.154.206]:46008 helo=AM1EHSOBE003.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy7ZW-0000B0-Rf for qemu-devel@nongnu.org; Mon, 29 Aug 2011 15:32:39 -0400 Message-ID: <4E5BE94D.20900@freescale.com> Date: Mon, 29 Aug 2011 14:32:29 -0500 From: Scott Wood MIME-Version: 1.0 References: <9F6FE96B71CF29479FF1CDC8046E15031B3313@039-SN1MPN1-002.039d.mgd.msft.net> <4E5BE2A5.7040201@codemonkey.ws> In-Reply-To: <4E5BE2A5.7040201@codemonkey.ws> Content-Type: text/plain; charset="ISO-8859-1" 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: Anthony Liguori Cc: Wood Scott-B07421 , "kvm@vger.kernel.org" , "Joerg.Roedel@amd.com" , "qemu-devel@nongnu.org" , Alexander Graf , Yoder Stuart-B08248 , "alex.williamson@redhat.com" , "avi@redhat.com" , David Gibson On 08/29/2011 02:04 PM, Anthony Liguori wrote: > On 08/29/2011 11:51 AM, Yoder Stuart-B08248 wrote: >> 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? This is more extensible than a struct -- both in features, and in the number of each type of resource that you can have, length of strings you can have, etc. > 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. There's no intent to replicate config space in general -- config space is provided as-is. There's little overlap between config space and the extra information provided. Length can be had from config space, but only by modifying it. Physical address sort-of overlaps, though bus addresess could be different from CPU physical addresses[1]. In both cases, it'd be nice to stay consistent with device-tree regions. "BAR type" is overlap, but doesn't seem too unreasonable to me. -Scott [1] The user is probably less likely to care about the physical address at all in the PCI case, but consistency is nice.