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

[Alex Bligh]

--On 16 October 2013 14:56:12 +0000 Matthew Anderson 
<address@hidden> wrote:

> Hi Xiangyouxie,
>
> I personally haven't tried to solve the problem as yet but I've been in
> contact with Anders Fudali who was able to find the issue with the help
> of one of his developers.
>
> See below for his comments. I've love to hear from any of the devs that
> can explain the issue further because as far as I know it's still an
> issue although I haven't with tried any releases past 1.4.1.

It would be interesting to know whether this happens on a current qemu
(i.e. master/1.7/whatever, not 1.6).

The timeout code in main-loop.c has been changed. For context, in
1.4.2, this does:

   395 int main_loop_wait(int nonblocking)
   396 {
   397     int ret;
   398     uint32_t timeout = UINT32_MAX;
   399
   400     if (nonblocking) {
   401         timeout = 0;
   402     }
   403

and I can promise that code has been changed. This might have fixed
things or (in other cases) made an existing bug more obvious.

I'm not sure whether the RTC is meant to be generating some sort of
qemu_notify() here, or using a timer, or what, but it should be doing
something to break out of the select() loop. Stefan - any idea?

Alex

> ----------------------------------------
>
> We use QEMU-1.4.2 and Kernel-3.8.8 on our host machines. During the
> latest "RTC-freeze" we managed to strace the affected QEMU-process and
> one of our developers figured out that a file descriptor selector loops
> with a NULL value for timeout... we adjusted the source code for the
> file: main-loop.c and replaced UINT32_MAX with the value: 1000, see the
> diff below:
>
> 398c398,399
> <     uint32_t timeout = UINT32_MAX;
> ---
> >     /* uint32_t timeout = UINT32_MAX; */
> >     uint32_t timeout = 1000;
>
> I'm not sure IF this might have some other undesirable effects or
> consequence and why only Windows guests seems to be affected, but we've
> been running with this "fix" for > 3 days now and haven't seen the
> problem since.
>
> Thought to share this with you.
>
> Regards
>
> Anders Fudali
>
> ------------------------------
>
> From: Xiexiangyou [mailto:address@hidden
> Sent: Tuesday, 8 October 2013 5:39 PM
> To: Matthew Anderson
> Cc: address@hidden
> Subject: Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle
>
> Hi:
>          I have met the same bug that windows2008 guest stop
> receive the RTC ticks when it in idle status by fortuitous. When vnc
> connect, guest will resume to receive RTC ticks and the time run fast
> because of the coalesced timer
>
> HPET is diabled, and RTC is set "catchup", as following:
>   <clock offset='utc'>
>     <timer name='rtc' tickpolicy='catchup' track='guest'/>
>     <timer name='hpet' present='no'/>
>   </clock>
>
> My kvm module is version3.6. Should I upgrade it to latest version. Any
> suggestion is welcome !
>
> Thanks!
>
> --xiangyouxie                              
>               
>
> On Thu, Feb 21, 2013 at 06:16:10PM +0000, Matthew Anderson wrote:
> > If this isn't the correct list just let me know,
> >
> > I've run into a bug whereby a Windows guest (tested on Server 2008R2 and
> > 2012) no longer receives RTC ticks when it has been idle for a random
> > amount  of time. HPET is disabled and the guest is running Hyper-V
> > relaxed timers  (same situation without hv_relaxed). The guest clock
> > stands still and the  qemu process uses very little CPU (<0.5%, normally
> > it's >5% when the guest is  idle) . Eventually the guest stops
> > responding to network requests but if you  open the guest console via
> > VNC and move the mouse around it comes back to  life and QEMU replays
> > the lost RTC ticks and the guest recovers. I've also  been able to make
> > it recover by querying the clock over the network via the  net time
> > command, you can see the clock stand still for 30 seconds then it
> > replays the ticks and catches up.
> >
> > I've tried to reproduce the issue but it seems fairly illusive, the only
> > way  I've been able to reproduce it is by letting the VM's idle and
> > waiting.  Sometimes it's hours and sometimes minutes. Can anyone suggest
> > a way to  narrow the issue down?
> >
> > Qemu command line is-
> > /usr/bin/kvm -name SQL01 -S -M pc-0.14 -cpu qemu64,hv_relaxed
> > -enable-kvm -m  2048 -smp 2,sockets=2,cores=1,threads=1 -uuid
> > 5f54333b-c250-aa72-c979-39d156814b85 -no-user-config -nodefaults
> > -chardev
> > socket,id=charmonitor,path=/var/lib/libvirt/qemu/iHost-SQL01.monitor,ser
> > ver,nowait   -mon chardev=charmonitor,id=monitor,mode=control -rtc
> > base=localtime  -no-hpet -no-shutdown -device
> > piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2  -drive
> > file=/mnt/gluster1-norep/iHost/SQL01.qed,if=none,id=drive-virtio-disk0,f
> > ormat=qed,cache=writeback   -device
> > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=v
> > irtio-disk0   -drive
> > file=/mnt/gluster1-norep/iHost/SQL01-Data.qed,if=none,id=drive-virtio-di
> > sk2,format=qed,cache=writeback   -device
> > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk2,id=v
> > irtio-disk2   -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw
> > -device
> > ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
> > -netdev  tap,fd=29,id=hostnet0,vhost=on,vhostfd=39 -device
> > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:2c:8d:23,bus=pci.0,a
> > ddr=0x3   -chardev pty,id=charserial0 -device
> > isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0
> > -vnc  127.0.0.1:22 -vga cirrus -device
> > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
> >
> > Environment is -
> > Mainline 3.7.5 and 3.8.0
> > Qemu 1.2.2, 1.3.1 and 1.4.0



--
Alex Bligh