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
>
next prev parent 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 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).