OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-comment] [PATCH 2/5] virtio-blk spec: writeback cache enable improvements

Il 19/08/2013 18:44, James Bottomley ha scritto:
>>   The difference is that the SCSI RPC is very small, and the
>> complicated/evolving parts are at a different level, so the host and
>> guest code that implements the virtio-scsi spec is very small.
>> Those complicated/evolving parts are _still_ there, so the code needed
>> in the host to implement virtio-scsi is indeed much larger than
>> virtio-blk.  But it's a non-issue for a non-toy VMM because that code is
>> needed anyway, for example to support USB storage.
> It might be now, but once you've done the feature creep in the
> virtio-blk spec to support all of our user visible features (DIF,
> discard, etc.) you'll probably find that the need to translate the
> commands causes virtio-blk to grow faster than virtio-scsi.

Oh, definitely!  In fact, we've decided not to do much feature-creep in

There was none after this patch.  Rusty said discard would be borderline
but acceptable, but he already wasn't sure about write-zeroes.

>> And piggybacking on SCSI means that whenever a new feature comes along,
>> someone else is already doing the work to integrate into the Linux block
>> layer, to use it, to export it to userspace, etc.  This typically
>> happens before hosts implement the feature, so us virt people get a
>> large part of the work for free; we only need to implement the feature
>> in the host, because these feature rarely if ever affect the SCSI RPC
>> interface.  Instead, adding the smallest feature to virtio-blk always
>> necessitates updates to both the spec and the guest drivers, in addition
>> to the VMM (typically QEMU).
> Spec, possibly, since someone needs to be told about commands added to
> block, but it shouldn't need modification of correctly implemented
> drivers.  If the encapsulation were done right, the client would just
> send the correct commands, so no code growth.

Ah, I see what you mean now.  It's a different channel to describe
features.  That would be a virtio-blk v2 basically.  It would have made
sense if done in the beginning, but not now.

> But this is illustrative of the point.  When the block layer is patched
> to add more stuff (which has been happening quite a lot lately), you
> have to rev your spec and update all the guest and host drivers.  This
> is one of the reasons for the current SCSI architecture model: not to
> have to do this.
>>> For standards purposes, I'm not really sure
>>> how to proceed on this but I believe linux will be the only implementor
>>> of virtio-blk, right, so it probably doesn't matter.
>> There are Windows drivers for virtio-blk.
> Which are thus effectively emulator drivers.


But honestly I'm not sure what your point is... I'm submitting this
patch at Rusty's request in order to clean up IP issues.  It's already
part of the spec, of QEMU, of the guest drivers.  I don't plan on any
other feature creep in virtio-blk, or fwiw no one else doesn't.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]