From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Work around dhclient brokenness Date: Tue, 19 Aug 2008 12:12:48 +0300 Message-ID: <48AA8E90.7070404@qumranet.com> References: <1218829632-19037-1-git-send-email-aliguori@us.ibm.com> <48A95FC7.90105@qumranet.com> <20080818114425.GA20351@gondor.apana.org.au> <200808191045.20980.rusty@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Herbert Xu , Anthony Liguori , kvm@vger.kernel.org, Mark McLoughlin To: Rusty Russell Return-path: Received: from il.qumranet.com ([212.179.150.194]:49100 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752086AbYHSJMu (ORCPT ); Tue, 19 Aug 2008 05:12:50 -0400 In-Reply-To: <200808191045.20980.rusty@rustcorp.com.au> Sender: kvm-owner@vger.kernel.org List-ID: Rusty Russell wrote: > On Monday 18 August 2008 21:44:25 Herbert Xu wrote: > >> On Mon, Aug 18, 2008 at 02:40:55PM +0300, Avi Kivity wrote: >> >>> Isn't that turned on automatically for real hardware? And what's to >>> prevent a broken dhclient together with the (presumably) hacked up >>> initscripts that call ethtool? >>> >> Well the idea is that only a fixed guest would even know about >> enabling this. >> > > For those not following closely: We already have a method for the guest to > accept or reject features. Our problem is that the guest is already > accepting the CSUM feature: but one critical userspace app (dhcp-client) can't > actually handle it due to a bug. > > The proposal is to add another mechanism, whereby the host doesn't advertise > CSUM, but advertises a new CSUM2 feature. The driver doesn't accept this by > default: then guest userspace says "hey, I *really can* handle CSUM". This > would have to be done dby resetting the device in the ethtool callback > (that's how we renegotiate features). And guests need a special virtio hack > in their init scripts. > > This leaves the small number of current users without CSUM (and hence GSO > etc). Yet they might not use dhcp with bridging anyway. Worst of all, we > have to document this embarrassing workaround. > > Neither solution is good. But I don't think Anthony's hack looks so bad after > this. > Well, if changed to avoid random udp packets and focus on dhcp, okay. I'd still like a way to disable it from the host. Even when it does nothing it will force the header into the host cache, which may be different from the guest cache. -- error compiling committee.c: too many arguments to function