[Qemu-devel] virtio block device and sysfs

[Qemu-devel] virtio block device and sysfs

[Marc Haber]

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

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

[jvrao]

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.
> 
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

Thanks,
JV


> 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
> 

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

[Marc Haber]

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

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

[jvrao]

Marc Haber wrote:
> 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?

Here is the patch for the guest kernel. 

http://patchwork.kernel.org/patch/83873/

- JV

> 
> Greetings
> Marc
> 

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

[jvrao]

jvrao wrote:
> Marc Haber wrote:
>> 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?
> 
> Here is the patch for the guest kernel. 
> 
> http://patchwork.kernel.org/patch/83873/

Sorry..here is another one that can be helpful to give you a complete picture.

http://patchwork.kernel.org/patch/83874/


> 
> - JV
> 
>> Greetings
>> Marc
>>
> 
> 
> 
> 

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

[Marc Haber]

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

[Anthony Liguori]

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"
>    

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

John attempted this and it was reverted because the implementation 
exhausted the PCI config space.

Regards,

Anthony Liguori

> 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
>
>    

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

[Jamie Lokier]

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"
> >   
> 
> 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

Sounds good to me.

This is looking a bit similar to the user-specified names in
virtio-serial.  Is it worth looking for a generic, common mechanism to
pass user-specified names to all virtio device types?

-- Jamie

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

[john cooper]

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

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

[Marc Haber]

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

[john cooper]

Marc Haber wrote:
> 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.

Well, maybe.  But it is hard to argue with anyone calling the
ATA_IDENTIFY interface ugly -- it is.

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.

>> 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.

>> 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.

-john


-- 
john.cooper@third-harmonic.com

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

[john cooper]

john cooper wrote:
> Marc Haber wrote:
>> Hi,
>>
>> On Mon, Mar 22, 2010 at 02:26:11AM -0400, john cooper 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.

I found the old patch, tossed out the remaining pci and
ATA_IDENTIFY artifacts and brought it forward.  The result
is downright diminutive.

Patches and details follow.

-john
  
-- 
john.cooper@redhat.com

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

[Marc Haber]

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

[john cooper]

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.

Thanks,

-john

-- 
john.cooper@third-harmonic.com

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

[Marc Haber]

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

[Ryan Harper]

* 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

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

[Marc Haber]

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

[Marc Haber]

[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

[Markus Armbruster]

Ryan Harper <ryanh@us.ibm.com> writes:

> 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

When you respin, have a look at commit a0fef654.

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

[Marc Haber]

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

[Ryan Harper]

* Marc Haber <mh+qemu-devel@zugschlus.de> [2010-09-13 03:56]:
> 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.

It'll only be available to guests launched with newer qemu (0.13) as
virtio-blk serial support is a new feature.

> 
> 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

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com

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

[Marc Haber]

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

[Marc Haber]

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

[Marc Haber]

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/XXXXX

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

[john cooper]

Marc Haber wrote:
> 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/XXXXX
> 
> 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.
 
>> 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?

If you are only consuming 20 bytes in the config space
currently there shouldn't be a problem -- that's exactly
where I had started with this work.  The issue was
rather of emulating an ATA_IDENTIFY interface where qemu
was cobbling together the content of the user data to be
ultimately passed to the guest's application.

That data structure by convention consumes a legacy 512
byte disk sector which overflowed the expectation of a
256 byte limit on PCI config space.  The rationale was
to have qemu package up the data so the virtio driver
could simply treat it as opaque.   Note the motivation for
reuse of the ATA_IDENTIFY interface was that of leveraging
existing tools such as hdparm(8) (and its windows
counterpart) which already speak that convention.  So
there was a reason we wound up in this unhappy place.

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.

-john
  
-- 
john.cooper@redhat.com

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

[Jamie Lokier]

john cooper wrote:
> 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.

And it needn't have a 20 character limit.

-- Jamie

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

[john cooper]

Jamie Lokier wrote:
> john cooper wrote:
>> 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.
> 
> And it needn't have a 20 character limit.

Technically yes it can be longer.  Although IIRC the
20/21 byte assumption is fairly entrenched in
related code.  It may also be encouraged if the ATA
interface is used to expose the data (under windows
for instance).

-john 

-- 
john.cooper@redhat.com

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

[Marc Haber]

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/XXXXX
> > 
> > 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

[john cooper]

Marc Haber wrote:
> Hi,
> 
> On Mon, Mar 22, 2010 at 10:22:14AM -0400, john cooper wrote:
>> Marc Haber wrote:
>>> 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.

Internally the s/n string is currently limited to 20 bytes.

>> 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?

Unknown at this point.  That was part of my earlier motivation
to package up this information as an ATA_IDENTIFY command which
AFAIK is digestible by windows.
 
> Has my wish made its way on the official wishlist and/or roadmap?

I submitted a virtio-based patch a few weeks ago.  I'd been
waiting for a reply from you concerning the /sys support
you'd mentioned.  If that plan has fallen by the wayside
I'll forward a more robust ioctl patch to Rusty so we can
tie this off.

-john

-- 
john.cooper@redhat.com

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

[Paul Brook]

> > 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:

- 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.

Paul

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

[Marc Haber]

Hi,

On Mon, Mar 22, 2010 at 03:14:48PM +0000, 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

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

[Michael S. Tsirkin]

On Tue, Mar 09, 2010 at 03:34:07PM -0600, Anthony Liguori wrote:
> John attempted this and it was reverted because the implementation  
> exhausted the PCI config space.

Not config space really, John's implementation put ATA_IDENTITY
(512 bytes) in PCI IO memory, PCI spec limits each such BAR to 256 bytes.

-- 
MST

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

[Anthony Liguori]

On 03/22/2010 09:46 AM, Michael S. Tsirkin wrote:
> On Tue, Mar 09, 2010 at 03:34:07PM -0600, Anthony Liguori wrote:
>    
>> John attempted this and it was reverted because the implementation
>> exhausted the PCI config space.
>>      
> Not config space really, John's implementation put ATA_IDENTITY
> (512 bytes) in PCI IO memory, PCI spec limits each such BAR to 256 bytes.
>    

Yes, I should know better than to be sloppy with my words on this :-)

I meant, it exhausted the virtio pci config space which is limited by 
the maximum size of PCI IO memory.  In theory, virtio has no config 
space limitation but virtio pci does.

Regards,

Anthony Liguori

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

[Richard W.M. Jones]

On Sat, Mar 06, 2010 at 11:42:34PM +0100, 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.

At the risk of AOLing this old thread, /me too would like to see this.
It would significantly improve the reliability of mapping libguestfs
files to devices.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora