From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzXsu-0005tL-2V for qemu-devel@nongnu.org; Fri, 02 Sep 2011 13:50:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzXst-0004jU-2w for qemu-devel@nongnu.org; Fri, 02 Sep 2011 13:50:32 -0400 Received: from ch1ehsobe003.messaging.microsoft.com ([216.32.181.183]:25130 helo=ch1outboundpool.messaging.microsoft.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzXss-0004j0-Ur for qemu-devel@nongnu.org; Fri, 02 Sep 2011 13:50:31 -0400 Message-ID: <4E61175F.5070602@freescale.com> Date: Fri, 2 Sep 2011 12:50:23 -0500 From: Scott Wood MIME-Version: 1.0 References: <9F6FE96B71CF29479FF1CDC8046E15031B3313@039-SN1MPN1-002.039d.mgd.msft.net> <20110901200037.GP10989@redhat.com> <4E5FEA59.7070201@freescale.com> <20110902155710.GA18389@redhat.com> In-Reply-To: <20110902155710.GA18389@redhat.com> 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: "Michael S. Tsirkin" 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 09/02/2011 10:57 AM, Michael S. Tsirkin wrote: > 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. Why is this better? >>> 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. Their relationship to vfio regions, and their offsets in the fd, is not. >>> 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. No, as I understand it the point is to provide access through that fd, as well as information that is specific to that fd. Whether any particular extra bit of information gets included there is a question of convenience -- which should not be ignored in interface design. -Scott