Re: [Xen-devel] [PATCH] x86/time: update TSC stamp on restore from deep C-state

[Jan Beulich <jbeulich@suse.com>]

On 15.01.2020 13:47, Igor Druzhinin wrote:
> 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.

The AMD part is pretty new, and is - afaict - an exception compared
to everything else. Under PVH there's no respective ACPI data (iirc),
and we also don't surface MONITOR/MWAIT to HVM/PVH guests, making
mwait_idle_probe() bail early. I wonder whether this special
behavior on AMD Fam17 should be suppressed in this case.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel