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

[Xiexiangyou]

Hi Anderson,

RTC timer may stop after live migration if you set the rtc_clock = host_clock. 
Because the different hosts have different system time.
Rtc is waiting for the next_periodic_time after migrating, it may wait more 
longer. During the time, VM will lose one tick with great possibility,
and the RTC periodic timer interrupt is blocked by "ioapic->irr==1" in KVM 
module.
To solve the problem, you can try "rtc_clock = vm_clock"(HPET is ok because it 
using vm_clock). Like this:
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup' track='guest'/>
    <timer name='hpet' present='no'/>
  </clock>

I hope it will help you.

Best wishes
---
Xiexiangyou

-----Original Message-----
From: Matthew Anderson [mailto:address@hidden 
Sent: Monday, October 28, 2013 2:59 PM
To: 'Alex Bligh'; Xiexiangyou
Cc: Stefan Hajnoczi; address@hidden
Subject: RE: [Qemu-devel] BUG: RTC issue when Windows guest is idle

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.

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,downscript=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