Re: [XEN PATCH] x86/msr: Allow hardware domain to read package C-state residency counters

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.07.2023 01:27, Simon Gaiser wrote:
> Andrew Cooper:
>> On 18/07/2023 2:17 pm, Simon Gaiser wrote:
>>> Since it's limited to the hardware domain it should be safe and it's
>>> very useful to have access to this directly in dom0 when debugging power
>>> related things for example S0ix.
>>
>> You need a SoB.
> 
> Yeah, sorry.
> 
>> But, this is an area there things are subtly broken.  For package-scope
>> MSRs on single socket systems (which does include client systems), then
>> this happens to function.
>>
>> It does not function for core-scoped MSRs, or at all in a multi-socket
>> system.  In such scenarios, dom0 can be rescheduled to a CPU in a
>> different scope while it thinks it is sampling a single scope.
>>
>> This is one of the areas where dom0 and Xen end up fighting over the system.
>>
>> I agree that we want some way for dom0 to get this information, but I'm
>> afraid it's not as simple as just permitting access to the MSRs like this.
> 
> I see. So a generic solution is not so easy. Also even if there would be
> an interface for dom0, my main motivation was to be able to just use
> existing code like /sys/kernel/debug/pmc_core/package_cstate_show and
> turbostat. You can already read those PC-states via Xen's debug
> interface, but that's less convenient.
> 
> For those package-scoped MSRs, how about limiting them to single-socket
> systems?

No, that's all hackery that in the extreme case may be okay to have in
debug builds, but never in release ones. Even having such in debug
builds is problematic, because then we won't routinely test code paths
as used by release builds. When virtualized and trying to access real
MSRs (rather than properly virtualized ones), you need some sort of PV
solution. If you want stuff like that to show up in "standard
interfaces", you'll have to teach the code providing those to use
whatever the (perhaps to be added) PV interface is.

Jan