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. -- 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
