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
  
-- 
address@hidden