Am 02.04.2014 17:56, schrieb Michael S. Tsirkin:
> On Wed, Apr 02, 2014 at 04:42:08PM +0100, Peter Maydell wrote:
>> On 2 April 2014 16:33, Paolo Bonzini <pbonz...@redhat.com> wrote:
>>> The subsection already exists in one well-known enterprise Linux
>>> distribution, but for some strange reason the fields were swapped
>>> when forward-porting the patch to upstream.
>>>
>>> Limit headaches for said enterprise Linux distributor when the
>>> time will come to rebase their version of QEMU.
>>>
>>> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
>>> ---
>>> target-i386/machine.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/target-i386/machine.c b/target-i386/machine.c
>>> index 24bc373..168cab6 100644
>>> --- a/target-i386/machine.c
>>> +++ b/target-i386/machine.c
>>> @@ -569,8 +569,8 @@ static const VMStateDescription
>>> vmstate_msr_hypercall_hypercall = {
>>> .minimum_version_id = 1,
>>> .minimum_version_id_old = 1,
>>> .fields = (VMStateField []) {
>>> - VMSTATE_UINT64(env.msr_hv_hypercall, X86CPU),
>>> VMSTATE_UINT64(env.msr_hv_guest_os_id, X86CPU),
>>> + VMSTATE_UINT64(env.msr_hv_hypercall, X86CPU),
>>> VMSTATE_END_OF_LIST()
>>> }
>>
>> Surely this is a migration compatibility break and you need to bump
>> the version fields here?
>>
>> thanks
>> -- PMM
>
> Not if we fix it before we put out 2.0.
Is the version_id important for that enterprise distribution?
We usually didn't make this depend on the release but on individual
changes, so PMM has a point. If someone did a savevm on master and after
this patch tries to loadvm it, maybe nothing bad happens in this case
but something we could easily prevent.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
