Re: [Qemu-devel] virtio block device and sysfs
On Tue, Sep 14, 2010 at 09:43:22AM +0200, Marc Haber wrote: > On Mon, Sep 13, 2010 at 09:34:24AM -0500, Ryan Harper wrote: > > It'll only be available to guests launched with newer qemu (0.13) as > > virtio-blk serial support is a new feature. > > Thanks for the information, I'll wait for the next release (or the > time to locally build 0.13-rc for testing, whatever happens first). I now have qemu-kvm 0.14, and the serial "number" is imported to the guest just fine, and there is also already a udev rule present in Debian which will make the disk show up in /dev/disk/by-id/virtio-foo. Thank you very much for helping, I really appreciate that. 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
Re: [Qemu-devel] virtio block device and sysfs
On Mon, Sep 13, 2010 at 09:34:24AM -0500, Ryan Harper wrote: > It'll only be available to guests launched with newer qemu (0.13) as > virtio-blk serial support is a new feature. Thanks for the information, I'll wait for the next release (or the time to locally build 0.13-rc for testing, whatever happens first). 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
Re: [Qemu-devel] virtio block device and sysfs
Hi John and Ryan, On Tue, Jun 29, 2010 at 01:33:33PM -0500, Ryan Harper wrote: > 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). How is this going to work once the patches have been applied? Even qemu 0.11's -drive definition allows a serial= option, but currently (qemu-kvm 0.12.5, and 2.6.35.4 in the guest) the string passed to it isn't seen anywhere in the guest's /sys/block/vda. My test call was kvm -cdrom ~/bigstuff/grml64-small_sid_20100913.iso \ -drive file=test.qcow2,if=virtio,media=disk,serial=foo 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
Re: [Qemu-devel] virtio block device and sysfs
Hi, On Tue, Jun 29, 2010 at 02:03:52PM -0400, john cooper wrote: > Marc Haber wrote: > >>>> 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? > > Yes, Ryan picked up the guest-user interface and exported > the data as /sys. We just need the qemu side patch updated > and we should have this finally put to bed. Sounds really great! 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
Re: [Qemu-devel] virtio block device and sysfs
[re-send with correct sender] Hi, On Tue, Jun 29, 2010 at 01:33:33PM -0500, Ryan Harper wrote: > 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). That sounds really good. Do you want me to give some code a try? 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
Re: [Qemu-devel] virtio block device and sysfs
Hi, On Tue, Jun 29, 2010 at 01:33:33PM -0500, Ryan Harper wrote: > 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). That sounds really good. Do you want me to give some code a try? 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
Re: [Qemu-devel] virtio block device and sysfs
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? 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
Re: [Qemu-devel] virtio block device and sysfs
Hi, On Mon, Mar 22, 2010 at 03:14:48PM +, Paul Brook wrote: > > > John attempted this and it was reverted because the implementation > > > exhausted the PCI config space. > > > > I don't understand that. Existig hardware devices dump much more of > > their data such as vendor and model type information into the config > > space, how can using a field that real hardware uses exhaust the > > config space? > > I think you (collectively) are confusing three different things: Perfectly accepted. I don't know zilch about today's hardware, I am not a developer but only a systems administrator wishing for some more flexibility in a software that I use every day. > - PCI config space: Not used in any significant way other than the standard > fields (i.e. basic device ID and configuring BARs). Slow/hard to access. > > - PCI IO BAR: Used by virtio-pci devices to expose the virtio config space. > Extremely limited resource (max. 64k for the whole system). On real hardware > only really used for legacy interfaces because it's slow, cumbersome, and x86 > specific. Unfortunately it currently seems to lower overhead than MMIO on > KVM > :-( > > - PCI MEM BAR (usually MMIO): How real devices expose themselves. Relatively > large address space (megabytes) available. Looks like PCI MEM BAR may be the way to go. 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
Re: [Qemu-devel] virtio block device and sysfs
Hi, On Mon, Mar 22, 2010 at 10:22:14AM -0400, john cooper wrote: > Marc Haber wrote: > > On Tue, Mar 09, 2010 at 03:34:07PM -0600, Anthony Liguori wrote: > >> On 03/06/2010 04:42 PM, Marc Haber wrote: > >>> 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" > >>> > >> 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/X > > > > It the serial "number" can be alphanumeric, that would be great to have. > > It is simply a string of 20 characters, which AFAICT has > its roots in the ATA S/N convention along with many other > puzzling present day evils. That would be enough for my purposes, but more would be acceptable as well. > All that said, I like the alternate choice of adding a > special virtio request far better. It is actually simpler > (and more maintainable IMO) than going through the > gyrations of stuffing the S/N data through PCI config > space. Whatever is more easily implemented ;)How would a Windows installation see the label then? Has my wish made its way on the official wishlist and/or roadmap? 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
Re: [Qemu-devel] virtio block device and sysfs
Hi, 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. > 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. > 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. Does qemu have an issue tracker where a wishlist issue could be filed to have this tracked? 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
Re: [Qemu-devel] virtio block device and sysfs
Hi, On Tue, Mar 09, 2010 at 03:34:07PM -0600, Anthony Liguori wrote: > On 03/06/2010 04:42 PM, Marc Haber wrote: >> 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" >> > > 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/X It the serial "number" can be alphanumeric, that would be great to have. > John attempted this and it was reverted because the implementation > exhausted the PCI config space. I don't understand that. Existig hardware devices dump much more of their data such as vendor and model type information into the config space, how can using a field that real hardware uses exhaust the config space? 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
Re: [Qemu-devel] virtio block device and sysfs
Hi, On Tue, Mar 09, 2010 at 12:04:39PM -0800, jvrao wrote: > Here is the patch for the guest kernel. > > http://patchwork.kernel.org/patch/83873/ Thanks, the comment explained it for me. Are all those relevant patches in git head of qemu, so that I can actually try? Will it be necessary to adapt kvm as well, or will kvm automatically support this feature once they have merged qemu's changes? 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
Re: [Qemu-devel] virtio block device and sysfs
Hi, thanks for your answer. On Mon, Mar 08, 2010 at 05:17:03PM -0800, jvrao wrote: > 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. > > > Please check out this patch and follow the "mount_tag" ...it may be helpful > in explaining what you are looking for. > > http://www.mail-archive.com/qemu-devel@nongnu.org/msg26358.html I am afraid that my knowledge of virtio interna is not sufficient to fully understand the patch. Does the guest see the mount tag, and if so, how does it see it? 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
[Qemu-devel] virtio block device and sysfs
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" Since I don't have pretty much clue about kernel programming, I guess that one would need to have qemu/kvm support for the additional label to be passed to the emulated/virtualized guest, and a modification to the guest kernel virtio driver which needs to accept the information passed by the host and to generate the appropriate entry in /sys. Am I correct in my assumption? Can you say who I need to talk to to get advice about how to implement this (or to have it implemented, if it's easy enough)? Any hints will be appreciated. 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
