All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.