From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Juan Quintela <quintela@redhat.com>,
Alexander Graf <agraf@suse.de>,
qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
Paolo Bonzini <pbonzini@redhat.com>,
Paul Mackerras <paulus@samba.org>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [RFC PATCH] spapr: support time base offset migration
Date: Wed, 04 Sep 2013 11:13:17 +1000 [thread overview]
Message-ID: <5226892D.408@ozlabs.ru> (raw)
In-Reply-To: <5225AA73.5090901@suse.de>
On 09/03/2013 07:22 PM, Andreas Färber wrote:
> Am 03.09.2013 11:07, schrieb Alexey Kardashevskiy:
>> On 09/03/2013 06:42 PM, Andreas Färber wrote:
>>> Am 03.09.2013 09:31, schrieb Alexey Kardashevskiy:
>>>> diff --git a/target-ppc/machine.c b/target-ppc/machine.c
>>>> index 12e1512..d1ffc7f 100644
>>>> --- a/target-ppc/machine.c
>>>> +++ b/target-ppc/machine.c
> [...]
>>>> +static const VMStateDescription vmstate_timebase = {
>>>> + .name = "cpu/timebase",
>>>> + .version_id = 1,
>>>> + .minimum_version_id = 1,
>>>> + .minimum_version_id_old = 1,
>>>> + .pre_save = timebase_pre_save,
>>>> + .post_load = timebase_post_load,
>>>> + .fields = (VMStateField []) {
>>>> + VMSTATE_UINT64(timebase, ppc_tb_t),
>>>> + VMSTATE_INT64(tb_offset, ppc_tb_t),
>>>> + VMSTATE_UINT64(time_of_the_day, ppc_tb_t),
>>>> + VMSTATE_UINT32_EQUAL(tb_freq, ppc_tb_t),
>>>> + VMSTATE_END_OF_LIST()
>>>> + },
>>>> +};
>>>> +
>>>> const VMStateDescription vmstate_ppc_cpu = {
>>>> .name = "cpu",
>>>> .version_id = 5,
>>>> @@ -498,6 +538,10 @@ const VMStateDescription vmstate_ppc_cpu = {
>>>> VMSTATE_UINT64_EQUAL(env.insns_flags, PowerPCCPU),
>>>> VMSTATE_UINT64_EQUAL(env.insns_flags2, PowerPCCPU),
>>>> VMSTATE_UINT32_EQUAL(env.nb_BATs, PowerPCCPU),
>>>> +
>>>> + /* Time offset */
>>>> + VMSTATE_STRUCT_POINTER(env.tb_env, PowerPCCPU,
>>>> + vmstate_timebase, ppc_tb_t *),
>>>> VMSTATE_END_OF_LIST()
>>>> },
>>>> .subsections = (VMStateSubsection []) {
>>>
>>> Breaks the migration format. ;) You need to bump version_id and use a
>>> macro that accepts the version the field was added in as argument.
>>
>> Risking of being called ignorant, I'll still ask - is the patch below what
>> you mean? I could not find VMSTATE_STRUCT_POINTER_V and I do not believe it
>> is not there already.
>
> Usually the way we do it is to have VMSTATE_STRUCT_POINTER() call
> VMSTATE_STRUCT_POINTER_V() and thus VMSTATE_STRUCT_POINTER_TEST() call a
> new VMSTATE_STRUCT_POINTER_TEST_V(), to avoid code duplication of the
> core array entry. CC'ing Juan. Please do the VMState preparation in a
> separate patch.
>
> ppc usage looks fine.
>
>> btw why would it break? Just asking. Is it because the source may send what
>> the destination cannot handle? Named fields should stop the migration the
>> same way as version mismatch would have done.
>
> Nope, field names do not get transmitted, only the section names.
> (Otherwise random code refactorings could break the migration format.)
>
>> Or the source won't sent what the destination expects and we do not want
>> this destination guest to continue?
>
> There's an incoming stream of data from either live migration or a file,
> and QEMU must decide whether it can read and how to interpret the raw
> bytestream. It shouldn't just read random bytes into a new field when
> they were written from a different field.
>
>> Once I was told that migration between different versions of QEMU is not
>> supported - so what is the point of .version_id field at all?
>
> Not sure who told such a thing and in what context. On x86 we try to
> avoid version_id bumps by adding subsections to allow migration in both
> ways (including from newer to older) but for ppc, arm and all others we
> do require that new fields are marked as such. Whether migration is
> officially supported is a different matter from the VMState wire format.
Why is the approach different for x86 and ppc here? I can convert
VMSTATE_STRUCT_POINTER to a subsection, why should not I? Or ppc is not
mature enough and therefore there is no need to keep compatibility? Thanks.
>
> Regards,
> Andreas
>
>
>> alexey@ka1:~/pcipassthru/qemu$ git diff
>> diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
>> index 1c31b5d..7b624bf 100644
>> --- a/include/migration/vmstate.h
>> +++ b/include/migration/vmstate.h
>> @@ -499,6 +499,15 @@ extern const VMStateInfo vmstate_info_bitmap;
>> #define VMSTATE_STRUCT_POINTER(_field, _state, _vmsd, _type) \
>> VMSTATE_STRUCT_POINTER_TEST(_field, _state, NULL, _vmsd, _type)
>>
>> +#define VMSTATE_STRUCT_POINTER_V(_field, _state, _vmsd, _type, _version) { \
>> + .name = (stringify(_field)), \
>> + .version_id = (_version), \
>> + .vmsd = &(_vmsd), \
>> + .size = sizeof(_type), \
>> + .flags = VMS_STRUCT|VMS_POINTER, \
>> + .offset = vmstate_offset_value(_state, _field, _type), \
>> +}
>> +
>> #define VMSTATE_STRUCT_ARRAY(_field, _state, _num, _version, _vmsd, _type) \
>> VMSTATE_STRUCT_ARRAY_TEST(_field, _state, _num, NULL, _version, \
>> _vmsd, _type)
>> diff --git a/target-ppc/machine.c b/target-ppc/machine.c
>> index b4f447c..f79f38e 100644
>> --- a/target-ppc/machine.c
>> +++ b/target-ppc/machine.c
>> @@ -501,7 +501,7 @@ static const VMStateDescription vmstate_timebase = {
>>
>> const VMStateDescription vmstate_ppc_cpu = {
>> .name = "cpu",
>> - .version_id = 5,
>> + .version_id = 6,
>> .minimum_version_id = 5,
>> .minimum_version_id_old = 4,
>> .load_state_old = cpu_load_old,
>> @@ -540,8 +540,8 @@ const VMStateDescription vmstate_ppc_cpu = {
>> VMSTATE_UINT32_EQUAL(env.nb_BATs, PowerPCCPU),
>>
>> /* Time offset */
>> - VMSTATE_STRUCT_POINTER(env.tb_env, PowerPCCPU,
>> - vmstate_timebase, ppc_tb_t *),
>> + VMSTATE_STRUCT_POINTER_V(env.tb_env, PowerPCCPU,
>> + vmstate_timebase, ppc_tb_t *, 6),
>> VMSTATE_END_OF_LIST()
>> },
>> .subsections = (VMStateSubsection []) {
>
--
Alexey
next prev parent reply other threads:[~2013-09-04 1:13 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-03 7:31 [Qemu-devel] [RFC PATCH] spapr: support time base offset migration Alexey Kardashevskiy
2013-09-03 8:42 ` Andreas Färber
2013-09-03 9:07 ` Alexey Kardashevskiy
2013-09-03 9:22 ` Andreas Färber
2013-09-04 1:13 ` Alexey Kardashevskiy [this message]
2013-09-04 1:27 ` Alexander Graf
2013-09-05 4:30 ` David Gibson
2013-09-05 4:54 ` Alexey Kardashevskiy
2013-09-05 9:16 ` Alexander Graf
2013-09-05 9:48 ` Alexey Kardashevskiy
2013-09-05 9:58 ` Alexander Graf
2013-09-05 11:44 ` Benjamin Herrenschmidt
2013-09-05 12:37 ` Alexander Graf
2013-09-05 13:36 ` Benjamin Herrenschmidt
2013-09-05 13:39 ` Alexander Graf
2013-09-05 14:14 ` Andreas Färber
2013-09-05 14:26 ` Benjamin Herrenschmidt
2013-09-05 15:11 ` Alexander Graf
2013-09-09 2:40 ` Alexey Kardashevskiy
2013-09-09 5:50 ` Alexander Graf
2013-09-09 5:58 ` Alexey Kardashevskiy
2013-09-09 6:06 ` Alexander Graf
2013-09-09 9:29 ` Benjamin Herrenschmidt
2013-09-09 9:32 ` Alexander Graf
2013-09-09 9:38 ` Benjamin Herrenschmidt
2013-09-09 9:41 ` Alexander Graf
2013-09-13 5:20 ` David Gibson
2013-09-13 18:06 ` Alexander Graf
2013-09-05 11:42 ` Benjamin Herrenschmidt
2013-09-05 12:09 ` Alexey Kardashevskiy
2013-09-06 3:00 ` David Gibson
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=5226892D.408@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=david@gibson.dropbear.id.au \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=quintela@redhat.com \
/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.