Re: [PATCH] Work around dhclient brokenness

[Avi Kivity <avi@qumranet.com>]

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