Re: [patch 0/7] force the TSC unreliable by reporting C2 state

[Anthony Liguori <anthony@codemonkey.ws>]

Marcelo Tosatti wrote:
> On Wed, Jun 18, 2008 at 04:02:39PM -0500, Anthony Liguori wrote:
>   
>>>> Have we yet determined why the TSC is so unstable in the first place? 
>>>>   In theory, it should be relatively stable on single-node Intel and  
>>>> Barcelona chips.
>>>>     
>>>>         
>>> If the host enters C2/C3, or changes CPU frequency, it becomes
>>> unreliable as a clocksource and there's no guarantee the guest will
>>> detect that.
>>>   
>>>       
>> On Intel, the TSC should be fixed-frequency for basically all shipping  
>> processors supporting VT.  Starting with 10h (Barcelona), I believe AMD  
>> also has a fixed frequency TSC.
>>     
>
> But still stops ticking in C2/C3 state, I suppose?
>   

I don't know for sure but the TSC is not tied to the CPU clock so I 
would be surprised if it did.  I think that that would defeat the 
utility of a fixed-frequency TSC.

Regards,

Anthony Liguori

>>> Also, as mentioned earlier, large systems with clustered APIC have
>>> unstable TSC.
>>>   
>>>       
>> Right, that's why I qualified with single-node.
>>
>>     
>>> We _could_ hook this fake-C2-state thing to the host TSC reliability:
>>>
>>> 1) Hook into Linux's mark_tsc_unstable().
>>> 2) On migration check if the destination host is using the TSC, if not, 
>>> force a faked-C2-state.
>>>
>>> Problem with 2) is that not all guests honour the ACPI _CST package
>>> notification (which would change C2's latency time from an unusable
>>> value to something usable). And now I don't think assuming the _CST
>>> notification to work is a good thing (after we found out that for ex.
>>> Ubuntu 7.10 kernel ignores it).
>>>   
>>>       
>> I think that for hosts with a known unstable TSC, we should do something  
>> like this.  But I also think we have a bug with TSC synchronization for  
>> AMD although I don't at all know what the source of it is.
>>     
>
> Chris has some patches around, I don't remember the details either.
>
> Thanks
>
>