All of lore.kernel.org
 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 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.