All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] virtio-blk: Something bizarre with VIRTIO_BLK_T_GET_ID
Date: Wed, 01 Aug 2012 17:03:40 -0500	[thread overview]
Message-ID: <878vdy2rsz.fsf@codemonkey.ws> (raw)
In-Reply-To: <1343796869.16975.48.camel@pasglop>

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> Hi Anthony !
>
> I was looking at virtio-blk.c as an example of some details regarding
> the use of virtio queues. One thing I'm implementing is a
> request/reponse model similar to what it does.
>
> One thing I noticed that sounds off to me but I might have missed
> something is the handling of the "GET_ID" request. Qemu does:
>
>     } else if (type & VIRTIO_BLK_T_GET_ID) {
>         VirtIOBlock *s = req->dev;
>
>         /*
>          * NB: per existing s/n string convention the string is
>          * terminated by '\0' only when shorter than buffer.
>          */
>         strncpy(req->elem.in_sg[0].iov_base,
>                 s->blk->serial ? s->blk->serial : "",
>                 MIN(req->elem.in_sg[0].iov_len, VIRTIO_BLK_ID_BYTES));
>         virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
>         g_free(req);
>     } ...
>
> So it basically writes up to VIRTIO_BLK_ID_BYTES bytes (which is 20)
> into the "in" iov (it doesn't walk the sg list, so it's a bit fishy,
> it assumes the guest is using a single entry here but that's not my
> problem).
>
> However, virtio_blk_req_complete() does:
>
>     virtqueue_push(s->vq, &req->elem, req->qiov.size + sizeof(*req->in));
>
> So it pushes into the queue req->qiov.size (which is 0) + sizeof(*req->in)
> which is as far as I can tell ... 16.

It's completely bogus.  Non-read/write commands probably need special
handling for push.

Regards,

Anthony Liguori

>
> So we don't push enough bytes out basically for the full 20 bytes allowed
> for the ID.
>
> Or am I missing something ?
>
> Cheers,
> Ben.

      parent reply	other threads:[~2012-08-01 22:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-01  4:54 [Qemu-devel] virtio-blk: Something bizarre with VIRTIO_BLK_T_GET_ID Benjamin Herrenschmidt
2012-08-01 10:16 ` Stefan Hajnoczi
2012-08-01 10:27   ` Benjamin Herrenschmidt
2012-08-01 10:31     ` Stefan Hajnoczi
2012-08-01 22:03 ` Anthony Liguori [this message]

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=878vdy2rsz.fsf@codemonkey.ws \
    --to=aliguori@us.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=qemu-devel@nongnu.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 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.