RE: [Xen-devel] [Patch] time resolution fix.

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

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

Attachment: Guest time.ppt
Description: Guest time.ppt

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel