Message ID | 1242574999-20887-14-git-send-email-aliguori@us.ibm.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Anthony Liguori wrote: > When TAP_VNET_HDR eventually merges into upstream QEMU, it cannot change the > format of the version 6 savevm data. This means that we're going to have to > bump the version up to 7. I'm happy to reserve version 7 as having TAP_VNET_HDR > support to allow time to include this support in upstream QEMU. > > For those shipping products based on KVM though, it's important that we do not > conflict with upstream QEMU versioning or else it's going to result in breakage > of backwards compatibility. > > Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> > Signed-off-by: Avi Kivity <avi@redhat.com> > Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> > > Duplicate signoff.
Avi Kivity wrote: > Anthony Liguori wrote: >> When TAP_VNET_HDR eventually merges into upstream QEMU, it cannot >> change the >> format of the version 6 savevm data. This means that we're going to >> have to >> bump the version up to 7. I'm happy to reserve version 7 as having >> TAP_VNET_HDR >> support to allow time to include this support in upstream QEMU. >> >> For those shipping products based on KVM though, it's important that >> we do not >> conflict with upstream QEMU versioning or else it's going to result >> in breakage >> of backwards compatibility. >> >> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> >> Signed-off-by: Avi Kivity <avi@redhat.com> >> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> >> >> > > Duplicate signoff. Do you care enough for me to resubmit? Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >>> When TAP_VNET_HDR eventually merges into upstream QEMU, it cannot >>> change the >>> format of the version 6 savevm data. This means that we're going to >>> have to >>> bump the version up to 7. I'm happy to reserve version 7 as having >>> TAP_VNET_HDR >>> support to allow time to include this support in upstream QEMU. >>> >>> For those shipping products based on KVM though, it's important that >>> we do not >>> conflict with upstream QEMU versioning or else it's going to result >>> in breakage >>> of backwards compatibility. >>> >>> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> >>> Signed-off-by: Avi Kivity <avi@redhat.com> >>> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> >>> >>> >> >> Duplicate signoff. > > Do you care enough for me to resubmit? > Not at all. Just being annoying :)
diff --git a/hw/virtio-net.c b/hw/virtio-net.c index 09e4b89..27620ba 100644 --- a/hw/virtio-net.c +++ b/hw/virtio-net.c @@ -21,7 +21,12 @@ #define TAP_VNET_HDR -#define VIRTIO_NET_VM_VERSION 6 +/* Version 7 has TAP_VNET_HDR support. This is reserved in upstream QEMU to + * avoid future conflict. + * We can't assume verisons > 7 have TAP_VNET_HDR support until this is merged + * in upstream QEMU. + */ +#define VIRTIO_NET_VM_VERSION 7 #define MAC_TABLE_ENTRIES 32 #define MAX_VLAN (1 << 12) /* Per 802.1Q definition */ @@ -652,8 +657,9 @@ static int virtio_net_load(QEMUFile *f, void *opaque, int version_id) qemu_get_buffer(f, (uint8_t *)n->vlans, MAX_VLAN >> 3); #ifdef TAP_VNET_HDR - if (qemu_get_be32(f)) + if (version_id == 7 && qemu_get_be32(f)) { tap_using_vnet_hdr(n->vc->vlan->first_client, 1); + } #endif if (n->tx_timer_active) {