All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>
Subject: Re: virtio message framing
Date: Fri, 13 Apr 2012 10:48:18 -0500	[thread overview]
Message-ID: <4F884AC2.9030202@us.ibm.com> (raw)
In-Reply-To: <CAJSP0QWPih2NmRvF3D-HXEH72t3pvvywoes-_wv2dAjHKg8Fjg@mail.gmail.com>

On 04/13/2012 09:50 AM, Stefan Hajnoczi wrote:
> The virtio specification says:
>
> "The descriptors used for a buff^[er should not eff^[ect the semantics
> of the message,
> except for the total length of the bu^[ffer"
>
> and
>
> "In particular, no implementation should use the descriptor boundaries
> to determine the size of any header in a request"

This was the noble intention but all of the implementations actually rely on 
boundary sizes.

Both QEMU and lguest rely on boundary sizes.  We've removed some of it in 
virtio-net in QEMU but it still looks like it's there for virtio-blk.

kvm tool also makes this assumption.

> Why should descriptor layout not be specified?
>
> It seems that implementing arbitrary descriptor layout support (e.g.
> 1-byte descriptors) requires more code and makes input validation
> harder.
>
> Why bother with the flexibility of unspecified descriptor layouts?  As
> long as the layout is specified clearly it makes everyone's lives
> easier to use a strict descriptor layout.

I hate to just change the spec here but I don't see a better option.

Regards,

Anthony Liguori

>
> The only reason I can think of is that virtio should work over
> transports that do not have the concept of "descriptors" (non-vring
> transports like pipes or streams).
>
> Stefan
>

  reply	other threads:[~2012-04-13 15:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-13 14:50 virtio message framing Stefan Hajnoczi
2012-04-13 15:48 ` Anthony Liguori [this message]
2012-05-07  3:12   ` Rusty Russell

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=4F884AC2.9030202@us.ibm.com \
    --to=aliguori@us.ibm.com \
    --cc=mst@redhat.com \
    --cc=stefanha@gmail.com \
    --cc=virtualization@lists.linux-foundation.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.