On 03/22/2011 09:32 PM, Peter Maydell wrote:
Just to make things more complicated, this has been deprecatedO:-)
It has? Your examples below still use it...
The case in which the subsection needed function returns true should
be rare, so the version number should rarely need to be bumped.
Peter Maydell peter.mayd...@linaro.org wrote:
On 22 March 2011 19:53, Juan Quintela quint...@redhat.com wrote:
Peter Maydell peter.mayd...@linaro.org 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
On 5 March 2011 16:50, Peter Maydell peter.mayd...@linaro.org wrote:
I've appended a draft of a suggested extra section for
docs/migration.txt so you can tell me if I've misunderstood
it all :-)
Ping? In particular if somebody can fill in the [XXX] bit for
me (and correct any other mistakes!)
Peter Maydell peter.mayd...@linaro.org wrote:
On 5 March 2011 14:59, Paolo Bonzini pbonz...@redhat.com wrote:
On 03/05/2011 01:34 PM, Peter Maydell wrote:
sorry, I miss this email before.
Ah. I was just following Juan's suggestion:
- if you don't care about backward compatibility, just add
On 22 March 2011 19:53, Juan Quintela quint...@redhat.com wrote:
Peter Maydell peter.mayd...@linaro.org 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
On 5 March 2011 17:04, Paolo Bonzini pbonz...@redhat.com wrote:
On 03/05/2011 05:50 PM, Peter Maydell wrote:
(1) Is there supposed to be any kind of guard on trying to
do a vmsave on a system with devices that don't implement
save/load? IME it just produces a snapshot which doesn't
work when
On 2011-03-07 12:45, Peter Maydell wrote:
On 5 March 2011 17:04, Paolo Bonzini pbonz...@redhat.com wrote:
On 03/05/2011 05:50 PM, Peter Maydell wrote:
(1) Is there supposed to be any kind of guard on trying to
do a vmsave on a system with devices that don't implement
save/load? IME it just
On 03/04/2011 09:34 PM, Peter Maydell wrote:
.name = realview_sysctl,
-.version_id = 1,
-.minimum_version_id = 1,
+.version_id = 2,
+.minimum_version_id = 2,
.fields = (VMStateField[]) {
VMSTATE_UINT32(leds, arm_sysctl_state),
On 5 March 2011 12:11, Paolo Bonzini pbonz...@redhat.com wrote:
On 03/04/2011 09:34 PM, Peter Maydell wrote:
.name = realview_sysctl,
- .version_id = 1,
- .minimum_version_id = 1,
+ .version_id = 2,
+ .minimum_version_id = 2,
.fields = (VMStateField[]) {
On 03/05/2011 01:34 PM, Peter Maydell wrote:
+VMSTATE_UINT32(sys_cfgdata, arm_sysctl_state),
+VMSTATE_UINT32(sys_cfgctrl, arm_sysctl_state),
+VMSTATE_UINT32(sys_cfgstat, arm_sysctl_state),
VMSTATE_END_OF_LIST()
}
You need to present the
On 5 March 2011 14:59, Paolo Bonzini pbonz...@redhat.com wrote:
On 03/05/2011 01:34 PM, Peter Maydell wrote:
Can you give an example/explanation? docs/migration.txt doesn't
seem to cover this...
Sure, sorry for being terse. It simply needs to be:
VMSTATE_UINT32_V(sys_cfgdata,
On 03/05/2011 05:50 PM, Peter Maydell wrote:
(1) Is there supposed to be any kind of guard on trying to
do a vmsave on a system with devices that don't implement
save/load? IME it just produces a snapshot which doesn't
work when you reload it...
I think you're right, devices currently have to
12 matches
Mail list logo
