All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.