Re: [PATCH] Work around dhclient brokenness

Avi Kivity
2008-08-19T09:12:50Z

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