[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: john cooper
Subject: Re: [Qemu-devel] virtio block device and sysfs
Date: Mon, 22 Mar 2010 02:26:11 -0400
User-agent: Thunderbird (X11/20071115)

Jamie Lokier wrote:
Anthony Liguori wrote:
On 03/06/2010 04:42 PM, Marc Haber wrote:

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

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]