Re: A testing for KVM

>-----Original Message-----
>From: Avi Kivity [mailto:avi@xxxxxxxxxxxx] 
>Sent: 2007年6月21日 17:01
>To: Dong, Eddie
>Cc: Gregory Haskins; kvm-devel@xxxxxxxxxxxxxxxxxxxxx
>Subject: Re: [kvm-devel] A testing for KVM
>
>Dong, Eddie wrote:
>> 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
>> 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.

>
>> 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
>> quit 
>> unnecessary, especially for X86-64 (faster processor).
>>
>> Another big issue is that guest Linux will eventually fail 
>back to PIT
>> 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.
>> 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
>> 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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/_______________________________________________
kvm-devel mailing list
kvm-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/kvm-devel