[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Big Bug:Time in VM running on xen goes slower


  • To: xen-devel <xen-devel@xxxxxxxxxxxxx>
  • From: tupeng212 <tupeng212@xxxxxxxxx>
  • Date: Tue, 7 Aug 2012 23:44:45 +0800
  • Delivery-date: Tue, 07 Aug 2012 15:45:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

Dear all:
I have found a big bug on xen concerning time virtualization. Please let me show you the whole process:
 
1 Phenomenon
when I run a JVM based program in IE browser in my Virtual Machine, I have found clearly that time at the right bottom corner in my VM gets more slower and slower.
I studied the bug deeply, and found something below.
 
2 Xen
vmx_vmexit_handler  --> ......... --> handle_rtc_io  --> rtc_ioport_write  --> rtc_timer_update --> set RTC's REG_A to a high rate--> create_periodic_time(disable the former timer, and init a new one)
Win7 is installed in the vm. This calling path is executed so frequent that may come down to set the RTC's REG_A hundreds of times every second but with the same rate(976.562us(1024HZ)), it is so abnormal to me to see such behavior.
 
3 OS
I have tried to find why the win7 setted RTC's regA so frequently. finally got the result, all that comes from a function: NtSetTimerResolution --> 0x70,0x71
when I attached windbg into the guest OS, I also found the source, they are all called from a upper system call that comes from JVM(Java Virtual Machine).
 
4 JVM
I don't know why JVM calls NtSetTimerResolution to set the same RTC's rate down (976.562us(1024HZ)) so frequently.
But found something useful, in the java source code, I found many palaces written with time.scheduleAtFixedRate(), Informations from Internet told me this function scheduleAtFixedRate demands a higher time resolution. so I guess the whole process may be this:
java wants a higher time resolution timer, so it changes the RTC's rate from 15.625ms(64HZ) to 976.562us(1024HZ), after that, it reconfirms whether the time is accurate as expected, but it's sorry to get some notice it 's not accurate either. so it sets  the RTC's rate from 15.625ms(64HZ) to 976.562us(1024HZ) again and again..., at last, results in a slow system timer in vm.
there is also a frequently called function going into my eyes: QueryPerformanceCounter.
 
 
what my problems are:
1 why the JVM sets the same RTC's rate 976562 down to the coms again and again? what he found  is abnormal?
2 even a abnormal user program calls create_periodic_time to set the rate again and again, how do we avoid the influence upon our time in vm? how do we compensate the elapsed time at the switching point? especially when the switch is so frequent.
 
can some big figures give me some advices on this?
thanks!

tupeng212
 
 
 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.