On Thu, 2007-06-21 at 11:23 +0800, Dong, Eddie wrote: > > > >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.
I'm not sure if this affects the TSC theory or not, but note that the host and guest have 250Hz PIT configured in the config. E.g. both kernels are programming the PIT to 250Hz, but guest is only seeing 125Hz ticks. If I "fix" the lost interrupt to bring the ticks to a true 250Hz, wall-clock time runs at 2x. Could it still be a TSC virtualization problem under these conditions? (I dont know much about TSC, so I just thought I would clarify this detail) ------------------------------------------------------------------------- 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