On 15/01/2020 12:39, Jan Beulich wrote:
> On 15.01.2020 13:28, Igor Druzhinin wrote:
>> On 15/01/2020 11:32, Jan Beulich wrote:
>>> On 14.01.2020 20:36, Igor Druzhinin wrote:
>>>> If ITSC is not available on CPU (e.g if running nested as PV shim)
>>>> then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
>>>> all AMD and some old Intel processors. In which case TSC would need to
>>>> be restored on CPU from platform time by Xen upon exiting deep C-states.
>>> How does waking from deep C states correspond to the PV shim? I notice
>>> that cstate_restore_tsc() gets called irrespective of the C state being
>>> exited, so I wonder whether there's room for improvement there
>>> independent of the issue at hand. As far as this change is concerned,
>>> I think you want to drop the notion of "deep" from the description.
>> I'm not familiar with what to call "deep C-state" so for me it was anything
>> higher than C1. If you prefer "deep" to be dropped - so be it.
> "Higher than C1" may be fine (albeit I vaguely recall TSC issues
> starting with C3 only), but at least mwait_idle() calls the
> function even for C1. As to the PV shim - does it know about any
> C-states at all (beyond HLT-invoked C1)?

Yes, PV-shim knows about C states as it looks they are tied to
processor ID in some cases. For AMD specifically C2 is HLT.


Xen-devel mailing list

Reply via email to