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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
