qemu-devel
[Top][All Lists]
Advanced

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

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


From: Cornelia Huck
Subject: Re: [PATCH 3/3] cpu-timers, icount: new modules
Date: Mon, 13 Jul 2020 12:46:04 +0200

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?




reply via email to

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