Re: [PATCH 18/18] Add timekeeping documentation

[Zachary Amsden]

On 07/13/2010 09:16 PM, Takuya Yoshikawa wrote:
> Hi,
>
> (2010/07/13 11:25), Zachary Amsden wrote:
> > +
> > +2.3) APIC
> > +
> > +On Pentium and later processors, an on-board timer is available to 
> > each CPU
> > +as part of the Advanced Programmable Interrupt Controller.  The APIC is
> > +accessed through memory-mapped registers and provides interrupt 
> > service to each
> > +CPU, used for IPIs and local timer interrupts.
> > +
> > +Although in theory the APIC is a safe and stable source for local 
> > interrupts,
> > +in practice, many bugs and glitches have occurred due to the special 
> > nature of
> > +the APIC CPU-local memory-mapped hardware.  Beware that CPU errata 
> > may affect
> > +the use of the APIC and that workarounds may be required.  In 
> > addition, some of
> > +these workarounds pose unique constraints for virtualization - 
> > requiring either
> > +extra overhead incurred from extra reads of memory-mapped I/O or 
> > additional
> > +functionality that may be more computationally expensive to implement.
> > +
> > +Since the APIC is documented quite well in the Intel and AMD 
> > manuals, we will
> > +avoid repititon of the detail here.  It should be pointed out that 
> > the APIC
>
>          repetition?
>
> > +timer is programmed through the LVT (local vector timer) register, 
> > is capable
> > +of one-shot or periodic operation, and is based on the bus clock 
> > divided down
> > +by the programmable divider register.
> > +
> > +2.4) HPET
> > +
> > +HPET is quite complex, and was originally intended to replace the 
> > PIT / RTC
> > +support of the X86 PC.  It remains to be seen whether that will be 
> > the case, as
> > +the de facto standard of PC hardware is to emulate these older 
> > devices.  Some
> > +systems designated as legacy free may support only the HPET as a 
> > hardware timer
> > +device.
> > +
> > +The HPET spec is rather loose and vague, requiring at least 3 
> > hardware timers,
> > +but allowing implementation freedom to support many more.  It also 
> > imposes no
> > +fixed rate on the timer frequency, but does impose some extremal 
> > values on
> > +frequency, error and slew.
> > +
> > +In general, the HPET is recommended as a high precision (compared to 
> > PIT /RTC)
> > +time source which is independent of local variation (as there is 
> > only one HPET
> > +in any given system).  The HPET is also memory-mapped, and its 
> > presence is
> > +indicated through ACPI tables by the BIOS.
> > +
> > +Detailed specification of the HPET is beyond the current scope of this
> > +document, as it is also very well documented elsewhere.
> > +
>
>
> > +3.6) TSC and STPCLK / T-states
> > +
> > +External signals given to the processor may also have the affect of 
> > stopping
>
>                                                              effect?
>
> > +the TSC.  This is typically done for thermal emergency power control 
> > to prevent
> > +an overheating condition, and typically, there is no way to detect 
> > that this
> > +condition has happened.
> > +
>
>
> > +4.4) Migration
> > +
> > +Migration of a virtual machine raises problems for timekeeping in 
> > two ways.
> > +First, the migration itself may take time, during which interrupts 
> > cannot be
> > +delivered, and after which, the guest time may need to be caught 
> > up.  NTP may
> > +be able to help to some degree here, as the clock correction 
> > required is
> > +typically small enough to fall in the NTP-correctable window.
> > +
> > +An additional concern is that timers based off the TSC (or HPET, if 
> > the raw bus
> > +clock is exposed) may now be running at different rates, requiring 
> > compensation
> > +in some may in the hypervisor by virtualizing these timers.  In 
> > addition,
>
>            way?
>
> > +migrating to a faster machine may preclude the use of a passthrough 
> > TSC, as a
> > +faster clock cannot be made visible to a guest without the potential 
> > of time
> > +advancing faster than usual.  A slower clock is less of a problem, 
> > as it can
> > +always be caught up to the original rate.  KVM clock avoids these 
> > problems by
> > +simply storing multipliers and offsets gainst the TSC for the guest 
> > to convert
>
>                                           against?
>
> > +back into nanosecond resolution values.
> > +
>
>
>   Takuya
>
>     -- I'm not English speaker, so not so sure about some places.

Thanks, you found some mistakes anyway, will fix.

Cheers,

Zach
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/