From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ND30L-0003ja-PR for qemu-devel@nongnu.org; Tue, 24 Nov 2009 16:32:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ND30H-0003iB-B4 for qemu-devel@nongnu.org; Tue, 24 Nov 2009 16:32:57 -0500 Received: from [199.232.76.173] (port=38897 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ND30H-0003i8-6p for qemu-devel@nongnu.org; Tue, 24 Nov 2009 16:32:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29648) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ND30G-0001Ir-Pm for qemu-devel@nongnu.org; Tue, 24 Nov 2009 16:32:53 -0500 Date: Tue, 24 Nov 2009 23:30:00 +0200 From: "Michael S. Tsirkin" Message-ID: <20091124213000.GA4614@redhat.com> References: <20091124194502.GA4250@redhat.com> <4B0C3901.5010100@linux.vnet.ibm.com> <20091124195458.GA4290@redhat.com> <4B0C4A6F.3000305@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0C4A6F.3000305@linux.vnet.ibm.com> Subject: [Qemu-devel] Re: [PATCH] qemu/virtio-net: remove wrong s/g layout assumptions List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Shirley Ma , Rusty Russell , qemu-devel@nongnu.org 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