qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <aliguori@linux.vnet.ibm.com>
Cc: Shirley Ma <mashirle@us.ibm.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH] qemu/virtio-net: remove wrong s/g layout assumptions
Date: Tue, 24 Nov 2009 23:30:00 +0200	[thread overview]
Message-ID: <20091124213000.GA4614@redhat.com> (raw)
In-Reply-To: <4B0C4A6F.3000305@linux.vnet.ibm.com>

On Tue, Nov 24, 2009 at 03:04:47PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Tue, Nov 24, 2009 at 01:50:25PM -0600, Anthony Liguori wrote:
>>   
>>> Michael S. Tsirkin wrote:
>>>     
>>>> virtio net currently assumes that the first s/g element it gets is
>>>> always virtio net header. This is wrong.
>>>> There should be no assumption on sg boundaries.  For example, the guest
>>>> should be able to put the virtio_net_hdr in the front of the skbuf data
>>>> if there is room.  Get rid of this assumption, properly consume space
>>>> from iovec, always.
>>>>         
>>> Practically speaking, we ought to advertise a feature bit to let a   
>>> kernel know that we are no longer broken.
>>>
>>> Otherwise, there are a ton of old userspaces that will break with new 
>>>  guests.
>>>     
>>
>> My thinking is, first of all let's fix the bug.
>> We'll add a feature bit when or if some guest wants to use it.
>> Maybe this will be 100 years down the road when all old userspace
>> has died a natural death :)
>> Makes sense?
>>   
>
> I don't think it's useful to do this without adding a feature bit.
> If we don't add a feature bit, the guest kernel cannot rely on this  
> behavior so it means by definition this is dead code.


It's useful because this way I won't have to maintain the fix, and it
will make it possible for guests to experiment with layouts, without
hacking qemu. If someone wants to make it a product, that's a different
thing.

Also, it might be a valid thing for a guest to say that host needs to be
fixed. Not everyone might care about running on any possible broken qemu
version.

Finally - where do we draw the line? Does any bugfix need a feature bit?

> -- 
> Regards,
>
> Anthony Liguori

  reply	other threads:[~2009-11-24 21:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-24 19:45 [Qemu-devel] [PATCH] qemu/virtio-net: remove wrong s/g layout assumptions Michael S. Tsirkin
2009-11-24 19:50 ` [Qemu-devel] " Anthony Liguori
2009-11-24 19:54   ` Michael S. Tsirkin
2009-11-24 21:04     ` Anthony Liguori
2009-11-24 21:30       ` Michael S. Tsirkin [this message]
2009-11-24 21:57         ` Anthony Liguori
2009-11-24 22:20           ` Michael S. Tsirkin
2009-11-30 11:16             ` Michael S. Tsirkin

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=20091124213000.GA4614@redhat.com \
    --to=mst@redhat.com \
    --cc=aliguori@linux.vnet.ibm.com \
    --cc=mashirle@us.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rusty@rustcorp.com.au \
    /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).