Re: [Qemu-devel] virtio block device and sysfs

[john cooper <john.cooper@third-harmonic.com>]

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