From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
dkoch@cloudswitch.com, qemu-devel@nongnu.org,
Michael Roth <mdroth@linux.vnet.ibm.com>,
Blue Swirl <blauwirbel@gmail.com>,
khoa@us.ibm.com, Paolo Bonzini <pbonzini@redhat.com>,
Asias He <asias@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 09/12] iov: add iov_get_ptr() to reference vector data
Date: Thu, 22 Nov 2012 14:35:46 +0200 [thread overview]
Message-ID: <20121122123546.GB26387@redhat.com> (raw)
In-Reply-To: <20121122115823.GA13571@stefanha-thinkpad.redhat.com>
On Thu, Nov 22, 2012 at 12:58:23PM +0100, Stefan Hajnoczi wrote:
> On Thu, Nov 22, 2012 at 10:34:13AM +0100, Paolo Bonzini wrote:
> > Il 21/11/2012 19:32, Stefan Hajnoczi ha scritto:
> > > The iov_get_ptr() data returns a pointer to contiguous data within a
> > > vector. This allows the caller to manipulate data inside the vector
> > > without copying in/out using iov_from_buf()/iov_to_buf() when we know
> > > that data is contiguous within an iovec element.
> >
> > This works for you because you have a single byte to write. It would
> > not work for the SG_IO inhdr, which would need iov_to_buf().
>
> Guilty as charged, your honor. :)
>
> Let me give a few more details about the motivation for this function:
>
> In virtio-blk-data-plane we have an iovec[] array. In the read/write
> code path we discard the inhdr/outhdr so just the data buffers are left
> in the iovec[] array. Then we can pass the iovec[] array straight to
> the Linux AIO functions.
>
> Because we're using the iovec[] array for data buffers and we're not
> allowed to make assumptions about iovec layout, we cannot use
> iov_to_buf()/iov_from_buf() at the end to fill in the status field - the
> inhdr has already been discarded from the iovec[] array.
How about using iov_copy?
We have exactly this problem in virtio net if we run
on host that does not support mergeable buffer header,
and we solve it by copying out the iovec.
> Since I knew the inhdr is only 1 byte I decided against doing something
> like dynamically allocating/freeing a QEMUIOVector which could handle
> spanning iovecs.
>
> That said, I think this function is okay as-is because it works fine for
> non-virtio cases where the caller *knows* the iovec[] layout. As a
> utility function it stands on its own.
>
My concern is these APIs are unsafe to use: you get back a pointer and
you must verify length is not too big before access. Since the iov can
be manipulated by guest this looks like a good place to put extra
safeguards.
> > What about the following alternative API:
> >
> > void *iov_get_ptr(struct iovec *iov, unsigned int iov_cnt,
> > ssize_t offset, size_t *bytes);
> >
> > which would place the number of valid bytes (i.e. the length of the
> > remainder of the iovec entry) in *bytes?
> >
> > Also, I think that offset == iov_size(iov, iov_cnt) should be
> > acceptable, and it would be the only case in which *bytes == 0.
>
> Hmm...this may be more useful than the version I proposed since the
> caller can also use it to find out how many bytes are contiguous.
>
> Michael: Any concerns if I update the code to reflect Paolo's
> suggestion?
>
> Stefan
I'd prefer something that actually works for all cases
rather than making callers check and handle failure,
or reason why it can't fail.
--
MST
next prev parent reply other threads:[~2012-11-22 12:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-21 18:32 [Qemu-devel] [PATCH v3 00/12] virtio: virtio-blk data plane Stefan Hajnoczi
2012-11-21 18:32 ` [Qemu-devel] [PATCH v3 01/12] raw-posix: add raw_get_aio_fd() for virtio-blk-data-plane Stefan Hajnoczi
2012-11-21 18:32 ` [Qemu-devel] [PATCH v3 02/12] configure: add CONFIG_VIRTIO_BLK_DATA_PLANE Stefan Hajnoczi
2012-11-21 18:32 ` [Qemu-devel] [PATCH v3 03/12] dataplane: add host memory mapping code Stefan Hajnoczi
2012-11-26 14:46 ` Don Koch
2012-11-26 15:36 ` Stefan Hajnoczi
2012-11-21 18:32 ` [Qemu-devel] [PATCH v3 04/12] dataplane: add virtqueue vring code Stefan Hajnoczi
2012-11-21 18:32 ` [Qemu-devel] [PATCH v3 05/12] dataplane: add event loop Stefan Hajnoczi
2012-11-21 18:32 ` [Qemu-devel] [PATCH v3 06/12] dataplane: add Linux AIO request queue Stefan Hajnoczi
2012-11-21 18:32 ` [Qemu-devel] [PATCH v3 07/12] iov: add iov_discard() to remove data Stefan Hajnoczi
2012-11-21 18:32 ` [Qemu-devel] [PATCH v3 08/12] test-iov: add iov_discard() testcase Stefan Hajnoczi
2012-11-21 18:32 ` [Qemu-devel] [PATCH v3 09/12] iov: add iov_get_ptr() to reference vector data Stefan Hajnoczi
2012-11-22 9:34 ` Paolo Bonzini
2012-11-22 9:45 ` Michael S. Tsirkin
2012-11-22 9:52 ` Paolo Bonzini
2012-11-22 10:38 ` Michael S. Tsirkin
2012-11-22 10:54 ` Paolo Bonzini
2012-11-22 11:14 ` Michael S. Tsirkin
2012-11-22 11:58 ` Stefan Hajnoczi
2012-11-22 12:15 ` Paolo Bonzini
2012-11-22 12:35 ` Michael S. Tsirkin [this message]
2012-11-22 15:18 ` Stefan Hajnoczi
2012-11-21 18:32 ` [Qemu-devel] [PATCH v3 10/12] test-iov: add iov_get_ptr() test case Stefan Hajnoczi
2012-11-21 18:33 ` [Qemu-devel] [PATCH v3 11/12] dataplane: add virtio-blk data plane code Stefan Hajnoczi
2012-11-21 18:33 ` [Qemu-devel] [PATCH v3 12/12] virtio-blk: add x-data-plane=on|off performance feature Stefan Hajnoczi
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=20121122123546.GB26387@redhat.com \
--to=mst@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=asias@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=dkoch@cloudswitch.com \
--cc=khoa@us.ibm.com \
--cc=kwolf@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 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).