Re: [Qemu-devel] [PATCH 1/3] sun4u: split out NPT and INT_DIS into separate CPUTimer fields

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

On 08/01/16 14:05, Peter Maydell wrote:

> On 13 November 2015 at 17:54, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>> Currently there is confusion between use of these bits for the timer and timer
>> compare registers (while they both have the same value, the behaviour is
>> different). Split into two separate CPUTimer fields so we can always reference
>> the correct value.
>>
>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>> ---
>>  hw/sparc64/sun4u.c |   17 +++++++++++++----
>>  target-sparc/cpu.h |    2 ++
>>  2 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
>> index d6b929c..7153638 100644
>> --- a/hw/sparc64/sun4u.c
>> +++ b/hw/sparc64/sun4u.c
>> @@ -363,6 +363,8 @@ void cpu_put_timer(QEMUFile *f, CPUTimer *s)
>>      qemu_put_be32s(f, &s->frequency);
>>      qemu_put_be32s(f, &s->disabled);
>>      qemu_put_be64s(f, &s->disabled_mask);
>> +    qemu_put_be32s(f, &s->npt);
>> +    qemu_put_be64s(f, &s->npt_mask);
>>      qemu_put_sbe64s(f, &s->clock_offset);
>>
>>      timer_put(f, s->qtimer);
>> @@ -373,6 +375,8 @@ void cpu_get_timer(QEMUFile *f, CPUTimer *s)
>>      qemu_get_be32s(f, &s->frequency);
>>      qemu_get_be32s(f, &s->disabled);
>>      qemu_get_be64s(f, &s->disabled_mask);
>> +    qemu_get_be32s(f, &s->npt);
>> +    qemu_get_be64s(f, &s->npt_mask);
>>      qemu_get_sbe64s(f, &s->clock_offset);
>>
>>      timer_get(f, s->qtimer);
> 
> Hi. I was just rebasing my sparc convert-to-vmstate patchset, and I
> noticed this patch due to a conflict. This change breaks migration
> and vmstate save/restore compatibility for these boards.
> Making the field version-dependent is probably a bit awkward at
> this point because these are just subfields in the overall CPU
> state and share its version number (which in turn is shared with
> the 32-bit CPUs).
> 
> Not sure what you want to do here?

Hi Peter,

I'm not particularly worried about sun4u for the moment as there are
already other reasons why migration would fail, e.g. no
VMStateDescription for storing PCI interrupt state in the apb host bridge.

Last time I checked sun4m migration appeared to work under some very
light testing, so as long as this behaviour is preserved then I don't
see a problem.


ATB,

Mark.