Re: [PATCH 3/3] cpu-timers, icount: new modules

[Cornelia Huck <cohuck@redhat.com>]

On Fri, 10 Jul 2020 21:20:08 +0200
Claudio Fontana <cfontana@suse.de> wrote:

> >>> In short this goes away if I again set icount to enabled for qtest,
> >>> basically ensuring that --enable-tcg is there and then reenabling icount.
> >>>
> >>> qtest was forcing icount and shift=0 by creating qemu options, in order to misuse its counter feature,
> >>> instead of using a separate counter.
> >>>
> >>> Removing that ugliness we end up with different behavior of save/load, because vmstate will now suddenly not contain icount-related values anymore.
> >>> What I do not understand is why this causes a problem because save should just not store the icount state and load should just not load the icount state,
> >>> and why we die on the load of s390 keys state (it works just fine for other architectures).  
> > 
> > Yes, I don't really see why skeys is so special. No endianness stuff, I
> > assume?  
> 
> 
> No, does not seem to be the issue.

Hm, had been worth a thought.

> 
> I discovered a way simpler way to "fix" it: 
> 
> static bool icount_state_needed(void *opaque)
> {
>     return 1;
> }
> 
> Ie, making sure that the state is always saved/restored, even when unused.
> 
> Really weird.
> 
> I logged/debugged the vmstate code, and I can see that things seem symmetric between save and load when it comes to timers.
> 
> something puts 0s into the key somehow...

Maybe writing one 0 to many?