From: Ryan Harper <ryanh@us.ibm.com>
To: Marc Haber <mh+qemu-devel@zugschlus.de>
Cc: john cooper <john.cooper@redhat.com>,
john cooper <john.cooper@third-harmonic.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] virtio block device and sysfs
Date: Tue, 29 Jun 2010 13:33:33 -0500 [thread overview]
Message-ID: <20100629183333.GG1647@us.ibm.com> (raw)
In-Reply-To: <20100629181522.GH8174@torres.zugschlus.de>
* Marc Haber <mh+qemu-devel@zugschlus.de> [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
next prev parent reply other threads:[~2010-06-29 18:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-06 22:42 [Qemu-devel] virtio block device and sysfs Marc Haber
2010-03-09 1:17 ` jvrao
2010-03-09 8:21 ` Marc Haber
2010-03-09 20:04 ` jvrao
2010-03-09 20:06 ` jvrao
2010-03-09 21:15 ` Marc Haber
2010-03-09 21:34 ` Anthony Liguori
2010-03-21 16:16 ` Jamie Lokier
2010-03-22 6:26 ` john cooper
2010-03-22 12:42 ` Marc Haber
2010-03-22 14:59 ` john cooper
2010-03-25 5:30 ` john cooper
2010-06-29 18:15 ` Marc Haber
2010-06-29 18:03 ` john cooper
2010-06-29 20:20 ` Marc Haber
2010-06-29 18:33 ` Ryan Harper [this message]
2010-06-29 18:36 ` Marc Haber
2010-06-29 18:36 ` Marc Haber
2010-06-30 7:01 ` Markus Armbruster
2010-09-13 8:55 ` Marc Haber
2010-09-13 14:34 ` Ryan Harper
2010-09-14 7:43 ` Marc Haber
2011-03-10 12:14 ` Marc Haber
2010-03-22 12:38 ` Marc Haber
2010-03-22 14:22 ` john cooper
2010-03-22 16:24 ` Jamie Lokier
2010-03-22 16:33 ` john cooper
2010-04-22 20:30 ` Marc Haber
2010-04-22 20:48 ` john cooper
2010-03-22 15:14 ` Paul Brook
2010-04-22 20:33 ` Marc Haber
2010-03-22 14:46 ` [Qemu-devel] " Michael S. Tsirkin
2010-03-22 14:52 ` Anthony Liguori
2010-03-20 18:32 ` [Qemu-devel] " Richard W.M. Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100629183333.GG1647@us.ibm.com \
--to=ryanh@us.ibm.com \
--cc=john.cooper@redhat.com \
--cc=john.cooper@third-harmonic.com \
--cc=mh+qemu-devel@zugschlus.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).