>-----Original Message-----
>From: Avi Kivity [mailto:[EMAIL PROTECTED]
>Sent: 2007年6月21日 17:01
>To: Dong, Eddie
>Cc: Gregory Haskins; kvm-devel@lists.sourceforge.net
>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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
