From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 1/2] Increment virtio-net savevm version to avoid conflict with upstream QEMU. Date: Thu, 30 Apr 2009 08:39:00 -0500 Message-ID: <49F9A9F4.2040503@us.ibm.com> References: <1241038430-7444-1-git-send-email-aliguori@us.ibm.com> <1241038430-7444-2-git-send-email-aliguori@us.ibm.com> <1241065511.9646.586.camel@2710p.home> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Avi Kivity To: Alex Williamson Return-path: Received: from e6.ny.us.ibm.com ([32.97.182.146]:34060 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762047AbZD3NjD (ORCPT ); Thu, 30 Apr 2009 09:39:03 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n3UDf54d027573 for ; Thu, 30 Apr 2009 09:41:05 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n3UDd2uu079830 for ; Thu, 30 Apr 2009 09:39:02 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n3UDd28I017384 for ; Thu, 30 Apr 2009 09:39:02 -0400 In-Reply-To: <1241065511.9646.586.camel@2710p.home> Sender: kvm-owner@vger.kernel.org List-ID: 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