On 15/01/2020 12:54, Jan Beulich wrote: > 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.
Anything which knows it is virtualised should use hypercalls to yield, and failing that, hlt. A VM isn't going to get a plausible idea of C/P states (give or take our dom0 special case seeing the real APCI tables which is still an open problem.) ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
