From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzW6T-0000iL-A6 for qemu-devel@nongnu.org; Fri, 02 Sep 2011 11:56:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzW6R-0004uO-Ej for qemu-devel@nongnu.org; Fri, 02 Sep 2011 11:56:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzW6R-0004u9-4M for qemu-devel@nongnu.org; Fri, 02 Sep 2011 11:56:23 -0400 Date: Fri, 2 Sep 2011 18:57:11 +0300 From: "Michael S. Tsirkin" Message-ID: <20110902155710.GA18389@redhat.com> References: <9F6FE96B71CF29479FF1CDC8046E15031B3313@039-SN1MPN1-002.039d.mgd.msft.net> <20110901200037.GP10989@redhat.com> <4E5FEA59.7070201@freescale.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5FEA59.7070201@freescale.com> 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: Scott Wood 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 Thu, Sep 01, 2011 at 03:26:01PM -0500, Scott Wood wrote: > On 09/01/2011 03:00 PM, Michael S. Tsirkin wrote: > > That's a very rich interface, and easy to get wrong. > > AFAIK the only reason vfio uses read/write for PCI was to avoid inventing > > a custom interface. But if you do, it looks like a set of ioctls would > > be much easier? You can even fit the existing uio infrastructure if you like. > > How would it be easier than producing/parsing a static data structure? > What would it look like? For example, for a property X, instead of adding a structure with identifier X, implement ioctl GET_X. Userspace calls this ioctl, an error implies the property is not present. > > Here's another idea: all the information is likely already available > > in sysfs. > > The only major thing that is likely available elsewhere is PCI config > space, and that was not new to this proposal. > Most other material is specifically related to the vfio/dtio interface > (e.g. offsets into the file handle, arguments to the "get irq fd" ioctl, > mapping of dtio regions/interrupts to device tree nodes), and could not > be "useful to more than just vfio". For example resources are already there in sysfs. > > A way to query where the device is in sysfs > > would give you *a ton* of information, including the type etc, > > For PCI, the user has domain/bus/dev/fn which should be sufficient to > find that, if desired. For device-tree devices, there's a device tree > path provided for each region/interrupt. > > -Scott So you are saying the user already has sysfs path? I thought the point was to pass all info through a single fd.