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