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

[Thomas Huth]

On 09/07/2020 20.38, Claudio Fontana wrote:
> On 7/8/20 5:05 PM, Paolo Bonzini wrote:
>> On 08/07/20 17:00, Claudio Fontana wrote:
>>>> Bisectable, 100% failure rate, etc. :(  Can you split the patch in
>>>> multiple parts, specifically separating any rename or introducing of
>>>> includes from the final file move?
>>> Hi Paolo,
>>>
>>> will take a look!
>>>
>>> Is this captured by some travis / cirrus-ci / anything I can easily see the 
>>> result of?
>>>
>>>
>>
>> Nope, unfortunately we don't have an s390 CI.  But if you can get your
>> hands on one, just "./configure --target-list=s390x-softmmu && make &&
>> make check-block" will show it.
> 
> So this is tricky, but I am making some progress after getting my hands on 
> one.
> Maybe if someone understands s390 keys better, I could be clued in.
> 
> 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).

FYI, the s390 storage keys are just part of the RAM of the machine,
AFAIK they are in no way related to icount. To me it sounds like your
problem is that the migration stream got corrupted elsewhere and is now
just failing in the skey handler by accident.
Is there maybe an endianness bug around somewhere? s390x is one of the
last big endian hosts that is still around...

 Thomas