Re: [PATCH] Work around dhclient brokenness

[Rusty Russell <rusty@rustcorp.com.au>]

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.

Rusty.