From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59994 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OTfcy-0007Hv-VQ for qemu-devel@nongnu.org; Tue, 29 Jun 2010 14:33:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OTfcx-0007MM-7h for qemu-devel@nongnu.org; Tue, 29 Jun 2010 14:33:48 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:35266) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OTfcx-0007Le-2a for qemu-devel@nongnu.org; Tue, 29 Jun 2010 14:33:47 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o5TIUH6V024594 for ; Tue, 29 Jun 2010 12:30:17 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5TIXclK118358 for ; Tue, 29 Jun 2010 12:33:39 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5TIXbFQ028859 for ; Tue, 29 Jun 2010 12:33:37 -0600 Date: Tue, 29 Jun 2010 13:33:33 -0500 From: Ryan Harper Subject: Re: [Qemu-devel] virtio block device and sysfs Message-ID: <20100629183333.GG1647@us.ibm.com> References: <20100321161638.GA4174@shareable.org> <4BA70D83.4070806@third-harmonic.com> <20100322124224.GG30984@torres.zugschlus.de> <4BA785C8.5050702@third-harmonic.com> <20100629181522.GH8174@torres.zugschlus.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100629181522.GH8174@torres.zugschlus.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marc Haber Cc: john cooper , john cooper , qemu-devel@nongnu.org * Marc Haber [2010-06-29 13:16]: > Hi, > > I had lost this topic for more than a few weeks... > > On Mon, Mar 22, 2010 at 10:59:20AM -0400, john cooper wrote: > > Marc Haber wrote: > >> On Mon, Mar 22, 2010 at 02:26:11AM -0400, john cooper wrote: > >>> This is a tad ironic as that is how this saga begun. Namely stuffing > >>> 20 bytes of serial number string into the virtio-blk PCI config space > >>> on qemu's side and pushing it over to the guest driver. I exposed this > >>> to the guest app via a new ioctl cmd which itself was the original > >>> point of contention. Someone took issue with introducing a new > >>> interface citing the existence of ATA and SCSI counterparts. However > >>> dragging in the associated baggage in order to emulate those interfaces > >>> unintentionally bloated usage of the config space to the point of breakage. > >>> To address this I'd moved from using config space to an unused BAR which > >>> (understandably) didn't go over too well. Somewhere along the line Rusty > >>> posted a minimal alternative version which directly used a virtio request > >>> to retrieve the data from qemu which is arguably the right way to do the > >>> job. > >> > >> *argh* That sounds like politics. > > > > Well, maybe. But it is hard to argue with anyone calling the > > ATA_IDENTIFY interface ugly -- it is. > > Indeed. It was designed to interact with Hardware, not with software > trying to look like hardware. > > > Concerning qemu->virtio_blk communication, I don't think an > > argument to use PCI config space exists after one looks at > > the implementation of adding a new virtio request. > > Indeed. Frankly, I don't care too much about how the information is > passed into the guest as long as the guest can read what the host > said. (mis)using ATA data was only a naive approach since I know that > there is an existing interface. If there is a better one, even better. > > >>> That said we still had a dispute over what interface would be used to > >>> pass the S/N back to the guest: a new interface or reuse of an existing > >>> interface (eg: ATA IDENTIFY). That's where things fizzled when we > >>> couldn't immediately resolve the issue. So publishing the S/N in > >>> /sys would seem to side step this snag. > >> > >> Re-using an existing interface would probable make it easier for > >> non-Linux OSses to also take advantage of this, since their ATA driver > >> is already there. > > > > Exactly my singular motivation and honestly the only redeeming > > quality of propagating that crusty interface. > > But otoh, I will only use Linux on the guest side, and it is > motivation for other developers to build a virtio driver for their > favorite OS. > > >>> I could have swore I sent out a guest-driver-app-interface-less > >>> version of the patch using virtio to pass the S/N but didn't find it in > >>> the archives. I did however locate it and can bring it forward as a > >>> reference for the above if interest exists. > >> > >> If it brings the issue forward and gives me hope to be able to do what > >> I want to do in a reasonable time frame, why not. > > > > Just time. But I'll resurrect the patch so we don't have to go through > > all of this again. > > Did that work? We've got a sysfs 'serial' attribute for virtio-blk devices upstream[1]. I've got udev support for using this attribute to create disk/by-id (and a fix for by-path) symlinks[2]. All that remains is to re-spin/post the qemu virtio-blk serial patches[3] and get that in and we'll have the full stack working as I've already tested libvirt (which has disk serial support). 1. https://lists.linux-foundation.org/pipermail/virtualization/2010-June/015324.html 2. http://www.spinics.net/lists/hotplug/msg03931.html 3. http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01870.html > > Greetings > Marc > > -- > ----------------------------------------------------------------------------- > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 > Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com