Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration

[Andrey Korolyov]

On Thu, Aug 21, 2014 at 7:48 PM, Andrey Korolyov <address@hidden> wrote:
> On Sat, Aug 9, 2014 at 10:35 AM, Paolo Bonzini <address@hidden> wrote:
>>
>>> > Yeah, I need to sit down and look at the code more closely...  Perhaps a
>>> > cpu_mark_all_dirty() is enough.
>>>
>>> Hi Paolo,
>>>
>>> cpu_clean_all_dirty, you mean? Has the same effect.
>>>
>>> Marcin's patch to add cpu_synchronize_state_always() has the same
>>> effect.
>>>
>>> What do you prefer ?
>>
>> I'd prefer cpu_clean_all_dirty because you can call it from the APIC
>> load functions.  The bug with your patch is due to the APIC and to
>> migration, it's not in the way your patch touches the kvmclock
>> vmstate_change_handler.
>>
>> Paolo
>
> Hello,
>
>
> JFYI - Windows showing the same behavior after migration using bare
> 2.1 (frozen disk with latest virtio block drivers). Reverting agraf`s
> patches back plus Marcin`s fix saves the situation, so AFAICS problem
> is critical to M$ products on KVM.

Sorry, the test series revealed that the problem is still here, but
with lower hit ratio with modified 2.1-HEAD using selected argument
set. The actual root of the issue is in '-cpu
qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1000'
Windows-specific addition which can be traded for some idle CPU
consumption. Reproduction of bug is quite simple - fire up Windows VM,
migrate it two-three times and then try to log in using rdesktop/VNC -
if disk is frozen, login progress will freeze too. It is not so easy
to detect blocked I/O on Windows in the interactive session due to
lack of soft lockup warning equivalent, so one can try such a sequence
to check.