All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH for-2.0] target-i386: reorder fields in cpu/msr_hyperv_hypercall subsection
Date: Wed, 02 Apr 2014 18:10:24 +0200	[thread overview]
Message-ID: <533C3670.8080309@suse.de> (raw)
In-Reply-To: <20140402155651.GB11987@redhat.com>

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 <pbonzini@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 <pbonzini@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

  reply	other threads:[~2014-04-02 16:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-02 15:33 [Qemu-devel] [PATCH for-2.0] target-i386: reorder fields in cpu/msr_hyperv_hypercall subsection Paolo Bonzini
2014-04-02 15:38 ` Michael S. Tsirkin
2014-04-05 10:17   ` Peter Maydell
2014-04-02 15:42 ` Peter Maydell
2014-04-02 15:43   ` Paolo Bonzini
2014-04-02 15:56   ` Michael S. Tsirkin
2014-04-02 16:10     ` Andreas Färber [this message]
2014-04-02 16:17       ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=533C3670.8080309@suse.de \
    --to=afaerber@suse.de \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.