Hi Thomas,
On 7/14/20 4:35 PM, Thomas Huth wrote:
> On 14/07/2020 16.29, Claudio Fontana wrote:
>> Hello,
>>
>> I have some tiny progress in narrowing down this issue, possibly a qcow2
>> issue, still unclear,
>> but involving Kevin Wolf and Max Reitz.
>>
>>
>> The reproducer again:
>>
>>> --------------------------------------------cut-------------------------------------------
>>> diff --git a/cpus.c b/cpus.c
>>> index 41d1c5099f..443b88697a 100644
>>> --- a/cpus.c
>>> +++ b/cpus.c
>>> @@ -643,7 +643,7 @@ static void qemu_account_warp_timer(void)
>>>
>>> static bool icount_state_needed(void *opaque)
>>> {
>>> - return use_icount;
>>> + return 0;
>>> }
>>>
>>> static bool warp_timer_state_needed(void *opaque)
>>> --------------------------------------------cut-------------------------------------------
>>
>> This issue for now appears on s390 only:
>>
>> On s390 hardware, test 267 fails (both kvm and tcg) in the qcow2 backing
>> file part, with broken migration stream data in the s390-skeys vmsave (old
>> style).
> [...]
>> If someone has a good idea let me know - first attempts to reproduce on x86
>> failed, but maybe more work could lead to it.
>
small update: in the GOOD case (enough padding added) a qcow_merge() is
triggered for the last write of 16202 bytes.
In the BAD case (not enough padding added) a qcow_merge() is not triggered for
the last write of 16201 bytes.
Note: manually flushing with qemu_fflush in s390-skeys vmsave also works (maybe
got lost in the noise).
> Two questions:
>
> 1) Can you also reproduce the issue manually, without running iotest
> 267? ... I tried, but so far I failed.
Thanks for the suggestion, will try.
>
> 2) Since all the information so far sounds like the problem could be
> elsewhere in the code, and the skeys just catch it by accident ... have
> you tried running with valgrind? Maybe it catches something useful?
Nothing yet, but will fiddle with the options a bit more.
>
> Thomas
>
Ciao,
Claudio
