On 08/07/2009 11:47 AM, Mark McLoughlin wrote:
slirp has started using VLANClientState::opaque and this has caused the
kvm specific tap_has_vnet_hdr() hack to break because we blindly use
this opaque pointer even if it is not a tap client.
Add yet another hack to check that we're actually
slirp has started using VLANClientState::opaque and this has caused the
kvm specific tap_has_vnet_hdr() hack to break because we blindly use
this opaque pointer even if it is not a tap client.
Add yet another hack to check that we're actually getting called with a
tap client.
[Needed on
On Friday 07 August 2009, Mark McLoughlin wrote:
slirp has started using VLANClientState::opaque and this has caused the
kvm specific tap_has_vnet_hdr() hack to break because we blindly use
this opaque pointer even if it is not a tap client.
Add yet another hack to check that we're actually
On Fri, 2009-08-07 at 13:51 +0200, Arnd Bergmann wrote:
On Friday 07 August 2009, Mark McLoughlin wrote:
slirp has started using VLANClientState::opaque and this has caused the
kvm specific tap_has_vnet_hdr() hack to break because we blindly use
this opaque pointer even if it is not a tap
On Friday 07 August 2009, Mark McLoughlin wrote:
The vnet_hdr code in qemu-kvm.git is a hack which we plan to
(eventually) replace by allowing a nic to be paired directly with a
backend.
Your patch is fine, but I'd suggest since both are a hack we stick with
mine since it'll reduce merge
