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 17:31, James Bottomley ha scritto:
> Well, yes, effectively.  You only have two implemented VIRTIO drivers:
> virtio-scsi and virtio-blk, both of which emulate packet transport
> protocols.  Block is much more problematic because it's not really
> designed to be a wire protocol unlike SCSI.

SCSI is an RPC protocol, but the wire protocol is obviously left to the
transport.  So in this respect block and SCSI aren't really like night
and day.  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.

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

This is not hypothetical, it has already happened for discard and it
will happen sometime for write-zeroes.

> However, what you should be
> doing is mirroring the REQ_ protocol and have a side handshake to set
> the capability flags.  That will ensure that all block features just
> work (tm) in the same way.

That's roughly what virtio-blk does (though it was not kept up-to-date
with discard and write-zeroes).

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


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