| Message ID | 1241038430-7444-2-git-send-email-aliguori@us.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 2009-04-29 at 15:53 -0500, Anthony Liguori wrote: > -#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 It seems like you're saying you're only going to reserve version number 7, and not the 4 bytes of savevm we're using for version 7 here. Couldn't we fix this by adding a dummy patch to qemu to bump to version 7, and push/pop a 4 byte zero from the savevm? Then we could change the code below to >= 7. Qemu should probably puke on a savevm image with non-zero in this location until the kvm code gets merged. Looks like one byte would be more than sufficient if we wanted to make that change now too. Thanks, Alex > #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) { -- 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
Alex Williamson wrote: > On Wed, 2009-04-29 at 15:53 -0500, Anthony Liguori wrote: > >> -#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 >> > > It seems like you're saying you're only going to reserve version number > 7, and not the 4 bytes of savevm we're using for version 7 here. > Couldn't we fix this by adding a dummy patch to qemu to bump to version > 7, and push/pop a 4 byte zero from the savevm? Then we could change the > code below to >= 7. Qemu should probably puke on a savevm image with > non-zero in this location until the kvm code gets merged. Looks like > one byte would be more than sufficient if we wanted to make that change > now too. Thanks, > I'd rather just merge vnet into upstream QEMU as quickly as possible. All I have to do to reserve a field is just hope noone submits a patch incrementing version id until we submit vnet support :-) -- 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
diff --git a/hw/virtio-net.c b/hw/virtio-net.c index 5f5f2f3..ac8e030 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) {
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> --- hw/virtio-net.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)