Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle

[Paolo Bonzini]

Il 28/10/2013 07:58, Matthew Anderson ha scritto:
> Hi Alex,
> 
> I've been doing some testing with the latest git version and so far I haven't 
> seen a guest freeze in the same circumstances as before. 
> 
> A weird thing that has been happening is the RTC timer stopping after a live 
> migration. This happened in both 1.6.1 and the 1.6.50 git build. To replicate 
> the issue I was migrating to/from the same machine and anywhere between 1 and 
> 3 migrations the guest clock would stop. Connecting to the VNC console would 
> not get it running again. I've tried to replicate the issue with the HPET 
> enabled but the guest clock works flawlessly with it enabled.

Please try this:

(1) reproduce it with migration to file + restore from file

     to save, from QEMU monitor:
         migrate exec:cat>migr.ckp

     to restore, from command line:
         ... -incoming 'exec:cat migr.ckp'

(2) If the RTC stops after restoring, compress migr.ckp and place it
somewhere I can download it.

Thanks,

Paolo

> Guest VM is Windows 2008R2. Host is Ubuntu 13.04 (kernel 3.8.0-25-generic)
> Command line -
> /usr/local/bin/qemu-system-x86_64 -enable-kvm -nodefconfig -nodefaults 
> -daemonize -usb -chardev 
> socket,id=charmonitor,path=/var/run/based1/monitor/525ce3d009c437d678000002.monitor,server,nowait
>  -mon chardev=charmonitor,id=monitor,mode=control -chardev 
> socket,path=/var/run/based1/ga/525ce3d009c437d678000002.guestagent,server,nowait,id=qga0
>  -device virtio-serial -device 
> virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -pidfile 
> /var/run/based1/pid/525ce3d009c437d678000002.pid -vga cirrus -vnc 0.0.0.0:1 
> -M pc-i440fx-1.6 -m 1024 -smp sockets=1,cores=1,threads=1 -cpu 
> qemu64,+vme,+dts,+acpi,+dtes64,+vmx,+smx,+ssse3,+sse4_1,+sse4_2,+tpr_shadow,+vnmi,+flexpriority,+ept,+vpid,hv_relaxed,hv_spinlocks=0xffff,hv_vapic
>  -rtc base=utc,driftfix=slew --no-hpet -drive 
> aio=native,file=rbd:sata/525ce3d009c437d678000003,if=virtio,id=disk-525ce3d009c437d678000005,format=raw,cache=writeback,media=disk,index=0,addr=0xa
>  -netdev 
> tap,id=netdev-5264b6d46e53c81719000236,vhost=off,ifname=tap2,script=no,dow
nscript=no -device 
virtio-net-pci,netdev=netdev-5264b6d46e53c81719000236,id=interface-5264b6d46e53c81719000236,mac=9a:a5:63:64:6f:76,bus=pci.0,addr=0xb
 -incoming tcp:0:3004
> 
> Thanks
> -Matt
> 
> 
> -----Original Message-----
> From: Alex Bligh [mailto:address@hidden 
> Sent: Tuesday, 22 October 2013 5:36 PM
> To: Xiexiangyou; Matthew Anderson
> Cc: Stefan Hajnoczi; address@hidden; Alex Bligh
> Subject: Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle
> 
> 
> 
> --On 22 October 2013 08:28:08 +0000 Xiexiangyou <address@hidden>
> wrote:
> 
>> Hi:
>>
>> I have run windows2008r2 guest with qemu-1.5.1/1.6(I have not test the 
>> the newer  version) for long time, the issue (guest in hangup state) 
>> will come out.When guest  in hangup state, QEMU main thread is blocked 
>> in g_poll loop.
>>> 398c398,399
>>> <     uint32_t timeout = UINT32_MAX;
>>> ---
>>>>     /* uint32_t timeout = UINT32_MAX; */
>>>>     uint32_t timeout = 1000;
>>>
>> It seems can fix the problem, and rtc/hpet interrupt can inject into 
>> guest again  because of the "timeout", and guest will wake up . But 
>> maybe the issue is also exist,  because during the time before timeout 
>> , guest also will lose rtc/hpet ticks.
> 
> I do not think that is the correct fix for 1.5.1/1.6; what you are basically 
> doing is limiting the wait in the mainloop to one second (1.5.1/1.6 are in 
> milliseconds); however, I believe there may be other code that looks for 
> infinite timeouts. Either there is some other bug that this is masking (in 
> which case it may or may not be fixed in master / 1.7), or its a bug in the 
> timer stuff in 1.5.1/1.6 (which would not surprise me) which is likely to 
> have been fixed in master / 1.7.
> 
> --
> Alex Bligh
> 
>