From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ntbdv-0007IB-9i for qemu-devel@nongnu.org; Mon, 22 Mar 2010 03:01:43 -0400 Received: from [199.232.76.173] (port=56245 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ntbdt-0007I1-Qc for qemu-devel@nongnu.org; Mon, 22 Mar 2010 03:01:41 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Ntbdp-0007s2-UE for qemu-devel@nongnu.org; Mon, 22 Mar 2010 03:01:41 -0400 Received: from mx20.gnu.org ([199.232.41.8]:10745) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ntbdp-0007rW-Lf for qemu-devel@nongnu.org; Mon, 22 Mar 2010 03:01:37 -0400 Received: from dpc6682208002.direcpc.com ([66.82.208.2] helo=anvil.third-harmonic.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ntbdi-000355-1R for qemu-devel@nongnu.org; Mon, 22 Mar 2010 03:01:32 -0400 Message-ID: <4BA70D83.4070806@third-harmonic.com> Date: Mon, 22 Mar 2010 02:26:11 -0400 From: john cooper MIME-Version: 1.0 Subject: Re: [Qemu-devel] virtio block device and sysfs References: <20100321161638.GA4174@shareable.org> In-Reply-To: <20100321161638.GA4174@shareable.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marc Haber Cc: john cooper , qemu-devel@nongnu.org Jamie Lokier wrote: > Anthony Liguori wrote: >> On 03/06/2010 04:42 PM, Marc Haber wrote: >>> Hi, >>> >>> I am looking to get in touch with somebody who knows more about the >>> connection between host configuration, qemu, kvm, and the virtio block >>> device driver guest side than I know. >>> >>> My goal is to have a possibility to give a "speaking" name to any >>> block device handed into a guest instance by the host. That name >>> should be visible inside the guest, just as a LV is visible with its >>> name in the system running the LVM. >>> >>> For example I would like to say on the qemu or kvm command line >>> '-drive file=some-file,label=some-label,if=virtio', and have the >>> string "some-label" show up somewhere in /sys/block in the guest, much >>> as /sys/block/sda/device/model shows the hardware vendor and type for >>> a standard SATA disk. The guest could then handle the information >>> passed into it by the host with udev rules, allowing fstab constructs >>> like "mount /dev/virtio/block/by-label/some-label as /usr" Sorry, I missed Anthony's earlier mail. >> You probably would just want to plumb ,serial=X into the virtio-blk >> config space and have the driver use it. Then you can do >> /dev/block/by-id/XXXXX 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. 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. 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. -john -- john.cooper@third-harmonic.com