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: Wed, 25 Nov 2009 00:20:05 +0200	[thread overview]
Message-ID: <20091124222005.GA4724@redhat.com> (raw)
In-Reply-To: <4B0C56DC.4010608@linux.vnet.ibm.com>

On Tue, Nov 24, 2009 at 03:57:48PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> 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.
>>   
>
> Advertising a new feature is not hard.  It's one line of code in qemu  
> with Rusty's ACK.

Okay. Rusty, ACK?

>> 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?
>>   
>
> This is a spec bug, not a qemu bug IMHO.
>
> The kernel drivers have always behaved this way and when this was all  
> written originally, the semantics were never defined.  All the userspace  
> implementations relied on this.  The fact that the spec claims a  
> different behavior is a result of deciding that it should be different  
> after the fact.
>
> Thinking about it more, your patch is broken.  If you run it against a  
> really old guest, it will break badly.

>From what I can tell, my patch will behave exactly as
existing code does unless guest puts more data than virtio net hdr
size in the first element. In that last case, qemu called exit(1)
and I handle it properly.

> You assume that the guest header is always a fixed size.  It's not,  
> we've added fields as we've added feature bits.

Hmm. How so? Look at old qemu code I am replacing. qemu
just exits if header size is different from sizeof virtio_net_hdr.

> You actually have to  
> look at the set of Ack'd features bits to determine how large the header 
> is.

I think you are speaking about the mergeable header thing.
If you look at the code, I think you will see that I handle this
case correctly.

> Which is why I now remember why this has never changed.  It's a PITA :-)  
> I'm not even sure you can do it in a correct way.

I think I got it right. If not, let me know which feature is handled
wrong please.

> -- 
> Regards,
>
> Anthony Liguori

  reply	other threads:[~2009-11-24 22:22 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
2009-11-24 21:57         ` Anthony Liguori
2009-11-24 22:20           ` Michael S. Tsirkin [this message]
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=20091124222005.GA4724@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).