From: Paolo Bonzini <pbonzini@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] virtio scsi host draft specification, v2
Date: Wed, 01 Jun 2011 17:59:28 +0200 [thread overview]
Message-ID: <4DE661E0.6080709@redhat.com> (raw)
In-Reply-To: <20110601143619.GB14626@redhat.com>
On 06/01/2011 04:36 PM, Michael S. Tsirkin wrote:
> Ah, I think I understand now. Both sense and data have in
> fields that might only be used partially?
> In that case I think I agree: it's best to require the use of separate
> buffers for them, in this way used len will give you useful information
> and you won't need sense_len and data_len: just a flag to
> mark the fact that there*is* a sense buffer following.
If the device wants a sense buffer to be there always, that's sensible.
No flag needed here, then. Also, sense is always "in", there is no out.
But I do not understand how the used len helps me. If I read the spec
correctly, the length will be the number of bytes written, but this will
always point to after the last field. If sense or data are written
partially, this will not be written in the fields---in fact, virtio_blk
does contain both sense_len and residual. Its sense field is fixed
size, which is probably why it doesn't contain something like
datain_size (there is just one variable-size field).
Strictly speaking I wouldn't need dataout_size too, because I have only
one variable-size read-only field, but I prefer to be future-proof.
I think the following is a good compromise:
1) keep dataout_size, datain_size and sense_size;
2) dataout, datain and sense shall each start a separate buffer, and
sense shall be contained in a single buffer; it is permissible to put
sense and the subsequent fields in the same buffer. This will make it
easy for the QEMU implementation to pick up its iovecs.
It will also let the device detect mistakes in filling the data sizes.
In practice I expect 3 descriptors will be used (one direct for
read-only stuff up to data; one possibly indirect for data; one direct
for sense and other write-only stuff).
> However some questions:
> 1. I think you don't need numdatain/numdataout: each
> buffer can include in and out segments. Just tell device how many
> buffers are there.
I don't understand.
Paolo
next prev parent reply other threads:[~2011-06-02 0:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-20 8:21 [Qemu-devel] virtio scsi host draft specification, v2 Paolo Bonzini
2011-05-28 19:33 ` Stefan Hajnoczi
2011-05-30 9:22 ` Paolo Bonzini
2011-06-01 4:44 ` Stefan Hajnoczi
2011-06-01 8:49 ` Michael S. Tsirkin
2011-06-01 11:59 ` Paolo Bonzini
2011-06-01 12:51 ` Michael S. Tsirkin
2011-06-01 13:31 ` Paolo Bonzini
2011-06-01 14:36 ` Michael S. Tsirkin
2011-06-01 14:51 ` Avi Kivity
2011-06-02 10:42 ` Michael S. Tsirkin
2011-06-02 11:42 ` Avi Kivity
2011-06-02 11:56 ` Michael S. Tsirkin
2011-06-02 12:18 ` Avi Kivity
2011-06-01 15:59 ` Paolo Bonzini [this message]
2011-06-02 11:41 ` Michael S. Tsirkin
2011-06-02 12:02 ` Paolo Bonzini
2011-06-02 12:54 ` Michael S. Tsirkin
2011-06-01 13:46 ` Avi Kivity
2011-06-01 16:25 ` Paolo Bonzini
2011-06-01 16:29 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DE661E0.6080709@redhat.com \
--to=pbonzini@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.