Raj, Ashok wrote:
>>> cpu_acpi_idle()
>>> {
>>> switch(cstate_type) {
>>> case CPU_ACPI_C2/C3:
>>> tsc_base = read_TSC();
>>> apic_base = read_APIC_TIMER();
>>> start = read_HPET();
>>> /* TSC and ACPI timer lost */
>>> enter_deeper_cstate();
>>> end = read_HPET();
>>> re-initialize_TSC() { TSC= tsc_base + end - start }
>>> re-initialize_APIC() { APIC = apic_base + end - start }
>>> }
>>>
>>> Does this make sense?
>>>
>>>
>>>
>> Yes. This is close to what we plan to do. :-)
>>
>
> You can probably take it from another CPU that's not in deep-c state (if
> there is one?)
>
>
Yes. Our initial thoughts are to sync up with a running CPU
via cross call. We need to run performance experiments with
different implementations to see what the costs are.
> Are there any drift/calibaration issues when you consider taking HPET
> source to reinit lapic timer/tsc?
>
>> Are there systems where CPU_ACPI_C2 does not reset the TSC
>> and APIC state on existing hardware? If so we would like to avoid
>> needlessly restoring state.
>>
>>
>
> You probably want to decouple TSC stopping and LAPIC stopping.
>
> Nehalem tsc doesn't stop indicated by x86_feature bit (new and coming)
> But lapic timer still stops in deep c state.
>
Yes. We want to have idle-state to hardware state mapping information
available, so we know what to save/restore across each idle-state on a
specific machine.
Thank you,
Bill
