[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-devel] [Patch] time resolution fix.
Keir: Before this patch, we saw 2 issues: One is when a VM switch happens at HVM guest within PIT Interrupt Service Routine (ISR) time. There exist problem if we let guest see time jump in TSC (TSC is used to adjust PIT). Previously hypervisor try to minimize the jump seen by guest, but the resolution is one PIT period that is not enough. (TSC_OFFSET=0-pending_intr_nr *period). This situation is worse in IA32E. The second issue is that when HVM/SMP is enabled, APIC time calibration want to see a TSC duration of about 100000000 cycles so that ACPI timer frequency can be calibrated with IRQ disabled. This is un-achievable in previously code. Because at that time the guest IRQ is disabled and no PIT IRQ injection, thus guest time is frozen. Due to that, the guest can never see 100000000 cycles passed (TSC is frozen) and thus stuck there. Another benefit of this is that we can get much accurate guest calibration result that is previously a known issue on multiple VM case, and it is long time too. I have a much detail description in the attached slide, hope this helpful. BTW, due to SMP support and more time resource support (RTC and ACPI), we are planning to do some design modification to sync all those different kind of time. This patch is mainly for bug fix that exist for long time and block SMP effort. thx,eddie Keir Fraser wrote: > On 17 Mar 2006, at 14:39, Dong, Eddie wrote: > >> This patch fix HVM/VMX time resolution issue that cause IA32E >> complain "loss tick" occationally and APIC time calibration issue. >> >> not tested on SVM for slight common code change. > > This patch looks scary. Can you give more info about the problem and > how you solve it? It looks like you end up forcibly sync'ing the > guest's TSC rate to the PIT rate? Would that even be necessary if the > PIT emulation were moved into Xen, where it ought to be? > > On a slightly unrelated note, I think TSC rate management will start > to get exciting when we have HVM save/restore. What will happen if a > guest is restored on a machine with quite different TSC rate to the > machine it originally ran on? I was wondering whether the current > TSC_OFFSET feature that VMX supports might be extended to allow > control over TSC clock rate as well. For example, provide 'base' and > 'scale' values and apply following when guest executes RDTSC: > guest_tsc = (host_tsc - base) * scale + offset > > How do you guys see this working? > > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel
_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
Lists.xenproject.org is hosted with RackSpace, monitoring our