[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] virtio block device and sysfs
From: |
Marc Haber |
Subject: |
Re: [Qemu-devel] virtio block device and sysfs |
Date: |
Tue, 29 Jun 2010 20:15:22 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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,
Marc Haber <=