> >One of the things that I noticed during the development of the APIC >patchset that was quite odd: > >1) Linux guest was programming the PIT for 4ms. >2) QEMU was programming the sigalarm for 1ms >3) SIGALARM was only delivered every 8ms (probably maximum resolution >with this setup) so the timer-wheel injected two PIT interrupts per >SIGALARM. >4) Since PICs can generally only queue a single interrupt, the second >tick was always lost. > >HOWEVER (and this is where it gets really weird), linux wallclock time >in the guest runs at normal speed even with PIT at 1/2 freq. If I made >corrections such that every PIT tick is actually delivered to >the guest, >wallclock runs at 2x.
That is what I mean the time virtualization headache for today's Linux. We should inject all guest PIT irqs (Xen did so), but the guest code (probably Linux only) is referencing PIT time (port 40) with TSC time. Since we didn't virtualize TSC now, i.e. guest TSC = host TSC, guest OS will think there is losted PIT IRQ ticks(actually no), since guest see TSC goes forward but PIT IRQ arrives later. and thus add back those fake lost ticks. In this way we see guest time ticks 2X faster. 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 to http://www.xensource.com/files/summit_3/Xen_HVM_SMP.pdf) 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). 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. Thx,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
