kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm-devel <kvm@vger.kernel.org>,
	target-devel <target-devel@vger.kernel.org>
Subject: Re: vhost-scsi support for ANY_LAYOUT
Date: Tue, 27 Jan 2015 09:42:22 +0100	[thread overview]
Message-ID: <54C74F6E.6000805@redhat.com> (raw)
In-Reply-To: <1422340517.9532.26.camel@haakon3.risingtidesystems.com>



On 27/01/2015 07:35, Nicholas A. Bellinger wrote:
> Hi MST & Paolo,
> 
> So I'm currently working on vhost-scsi support for ANY_LAYOUT, and
> wanted to verify some assumptions based upon your earlier emails..
> 
> *) When ANY_LAYOUT is negotiated by vhost-scsi, it's expected that
> virtio-scsi request + response headers will (always..?) be within a
> single iovec.
> 
> *) When ANY_LAYOUT is negotiated by vhost-scsi, it's expected that
> virtio-scsi request + response headers may be (but not always..?)
> combined with data-out + data-in payloads into a single iovec.
> 
> *) When ANY_LAYOUT + T10_PI is negotiated by vhost-scsi, it's expected
> that PI and data payloads for data-out + data-in may be (but not
> always..?) within the same iovec.  Consequently, both headers + PI +
> data-payloads may also be within a single iovec.

s/expected/possible/g

Any split between header and payload is possible.  It's also possible to
split the header in multiple parts, e.g. put the CDB or sense buffer in
a separate iovec.  Even a single field could be split across two iovecs.

> *) Is it still safe to use 'out' + 'in' values from vhost_get_vq_desc()
> in order to determine the data_direction...?  If not, what's the
> preferred way of determining this information for get_user_pages_fast()
> permission bits and target_submit_cmd_map_sgls()..?

No, it's not safe.  What QEMU does is to check if the output buffers are
collectively larger than the request header, and if the input buffers
are collectively larger than the response header.  This lets you cpmpute
the data direction.

> Also, what is required on the QEMU side in order to start generating
> ANY_LAYOUT style iovecs to verify the WIP changes..? 

Nothing on the QEMU side.  You could test any-layout payloads by
changing the kernel side.  Splitting the sense buffer into its own iovec
for example is a trivial patch to drivers/scsi/virtio_scsi.c.

It also helps to adhere to coding conventions.  For example in QEMU I'm
never using iov[N], and I'm restricting usage of iovcnt to (iov, iovcnt)
parameter pairs.  This was suggested by Michael and found a couple bugs
indeed.

Paolo

  reply	other threads:[~2015-01-27  8:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-27  6:35 vhost-scsi support for ANY_LAYOUT Nicholas A. Bellinger
2015-01-27  8:42 ` Paolo Bonzini [this message]
2015-01-27  8:56   ` Paolo Bonzini
2015-01-27  8:58   ` Michael S. Tsirkin
2015-01-27  8:52 ` Michael S. Tsirkin

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=54C74F6E.6000805@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=nab@linux-iscsi.org \
    --cc=target-devel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).