qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH v2 1/2] hw/arm_sysctl.c: Add the Versatile Expre


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH v2 1/2] hw/arm_sysctl.c: Add the Versatile Express system registers
Date: Wed, 23 Mar 2011 10:44:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Peter Maydell <address@hidden> wrote:
> On 22 March 2011 19:53, Juan Quintela <address@hidden> wrote:
>> Peter Maydell <address@hidden> wrote:
>>> Migration from the old version to the new version can be supported
>>> if it is OK for the new fields to remain in their default state
>>> [XXX is this right? are they zeroed, or do they get the value
>>> the device's reset function sets them to, or something else?]
>>
>> You can initialize in your init function at the value that you want, or
>> use foo_post_load() function (that receives the version as a parameter)
>> to assign to any correct values that you need.
>
> To check I understand this, this means an incoming migration is
> always done to a fresh, never-been-used-before device that has had
> its init called but not its reset?
>
>>> when the state of an old-version snapshot is loaded. To implement
>>> this you need to use the VMSTATE_*_V macros which let you specify
>>> the version in which a field was introduced, for instance:
>>>
>>>  VMSTATE_UINT32_V(sys_cfgdata, arm_sysctl_state, 2)
>>>
>>> for a field introduced in version 2. You should also increment
>>> the version_id, but leave the minimum_version_id unchanged.
>>> Newly added VMSTATE_*_V fields should go at the end of the
>>> VMState description.
>>
>> Just to make things more complicated, this has been "deprecated" O:-)
>
> It has? Your examples below still use it...

as Paolo says, it should be rare that you need it.


>> - We know that old device was wrong, and that there is no way we can
>>  load (reliabely) from version 0.  Then we just increase the version:
>
> If you're increasing the version can you also clean up by
> converting any old VMSTATE_*_V() into plain VMSTATE_*() at this
> point, since we can't migrate from those old versions any more?

>From vl.c

    qemu_system_reset();
    if (loadvm) {
        if (load_vmstate(loadvm) < 0) {
            autostart = 0;
        }
    }

    if (incoming) {
        int ret = qemu_start_incoming_migration(incoming);
        if (ret < 0) {
            fprintf(stderr, "Migration failed. Exit code %s(%d), exiting.\n",
                    incoming, ret);
            exit(ret);
        }
    } else if (autostart) {
        vm_start();
    }


reset is always called after init, before both incoming migration and
normal start.

>> - We know that we can load from v1.  But that we want to always sent
>>  bar2 for migration, then we just increase versions to:
>>
>>
>> const VMStateDescription vmstate_foo = {
>>    .name = "foo",
>>    .version_id = 2,
>>    .minimum_version_id = 1,
>>    .minimum_version_id_old = 1,
>>    .fields      = (VMStateField []) {
>>        VMSTATE_INT32(bar, FOOState),
>>        VMSTATE_INT32_V(bar2, FOOState, 1),
>>        VMSTATE_END_OF_LIST()
>>    }
>> };
>>
>> And we are done.  We are able to receive state 0 and 1, and we would
>> always sent version 1.
>
> Your numbers in the struct and the text don't seem to match?
> My guess is you meant to write version_id = 1, minimum_version* = 0 ?

My fault. copy paste :-(

>> Have I manage to explain myself a little bit?
>
> Yes, thanks, that's very helpful.

You are welcome.

Later, Juan.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]