Re: A testing for KVM

-----Original Message-----
From: Avi Kivity [mailto:avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org] 
Sent: 2007年6月21日 17:01
To: Dong, Eddie
Cc: Gregory Haskins; kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [kvm-devel] A testing for KVM

Dong, Eddie wrote:

quoted

In Xen, we virtualize TSC too to make sure the guest TSC time is
synchronized with 
guest PIT time, so guest can see an accurate virtual time. (refer my
presentation
doc on Xen September summit 06.) It is good but time to time
we see bugs due to the complicated time virtualization 

mechanism. As far

quoted

as I know,
Vmware doesn't solve this problem either, it depends on guest
application to sync
guest time with real time (network or host). 

  

Do you mean that rdtsc is trapped?  Or that you play with 
TSC_OFFSET so 
that time is smoother?

Yes, change the TSC_OFFSET value in case a VM is descheduled. 
And adjust it back till all pending PIT irq is injected.

In Xen, we keep a notion of "guest time", so each time resource no matter 
guest PIT, RTC, PM timer or TSC time should sync with "guest time".

I mention this, but not suggest to implement same way since it is 
too complicated.

quoted

We can use PV time of linux, another way is to persuade community to
give up 
the cross reference of PIT and TSC to give up picking the lost ticks
given that 
today's OS is smart enough and won't disable IRQ for that long time
before
 another PIT expires (1-4ms), so those kind of picking up 

lost ticks is

quoted

quit 
unnecessary, especially for X86-64 (faster processor).

Another big issue is that guest Linux will eventually fail 

back to PIT

quoted

time source after
hundreds of "lost ticks" and thus give up TSC time source. This is OK
for normal application
but dead set for database server where gettimeofday is 

frequently used.

quoted

We saw
 30-40% performance degradation due to this only. (gettimeofday  will
read port 40
 multiple times which is extremely slow under virtualization).

I will ask Jun, Avi to bring this issue to virtualization 

mini summit to

quoted

persuade 
communitty to do some changes in guest timer IRQ handler.
  

For newer kernels, we can supply a paravirt clocksource (as in 
Anthony's 
patchset) which will  remove the need for changing the bare hardware 
time code.

Yes. but I am wondering about the performance. Hypercall to get 
host time should be expansive than hardware support TSC read which is
 about 200 cycles. I may make mistake since I didn't go through the patch
in very detail.

gettimeofday is very important :-)


Eddie