From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [Qemu-devel] RFC: vfio / device assignment -- layout of device fd files Date: Mon, 29 Aug 2011 14:32:29 -0500 Message-ID: <4E5BE94D.20900@freescale.com> References: <9F6FE96B71CF29479FF1CDC8046E15031B3313@039-SN1MPN1-002.039d.mgd.msft.net> <4E5BE2A5.7040201@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Yoder Stuart-B08248 , "alex.williamson@redhat.com" , Benjamin Herrenschmidt , Wood Scott-B07421 , "kvm@vger.kernel.org" , "Joerg.Roedel@amd.com" , "qemu-devel@nongnu.org" , Alexander Graf , "avi@redhat.com" , David Gibson To: Anthony Liguori Return-path: Received: from am1ehsobe003.messaging.microsoft.com ([213.199.154.206]:45998 "EHLO AM1EHSOBE003.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754797Ab1H2Tch (ORCPT ); Mon, 29 Aug 2011 15:32:37 -0400 In-Reply-To: <4E5BE2A5.7040201@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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.