Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.11.2019 16:45, Roger Pau Monné  wrote:
> On Thu, Nov 21, 2019 at 08:56:41PM +0530, Rishi wrote:
>> On Thu, Nov 21, 2019 at 7:26 PM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>>>
>>> On Thu, Nov 21, 2019 at 07:09:31PM +0530, Rishi wrote:
>>>> On Tue, Nov 19, 2019 at 2:47 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>>
>>>>> On 19.11.2019 06:23, Rishi wrote:
>>>>>> ok, thanks for clearing it up. Would a patch be accepted if this
>>>>>> option of showing EAX leaf is selectively done through command line
>>>>>> (default disabled)?
>>>>>
>>>>> In general I'd expect this to be rather unlikely, but I guess much
>>>>> would depend on the actual reasoning done in the description.
>>>>>
>>>>>> On longer run, what is an expected sane model of virtualizing this?
>>>>>> With some guidance, may be I or someone else can code to bring the
>>>>>> functionality back.
>>>>>
>>>>> Which functionality? So far you've talked of only CPUID bits I
>>>>> think, without explaining at all what functionality you want to
>>>>> have that depends on these. In general, as said earlier, CPU
>>>>> management is the hypervisor's responsibility, so I'd rather
>>>>> not see this virtualized, but the hypervisor be put into a
>>>>> position of doing whatever is needed.
>>>>>
>>>>> Jan
>>>>
>>>> The reasoning to have EAX(0x06h) exposed to Dom0 is for Thermal and
>>>> Power management.
>>>> Without EAX(0x06h) Dom0 is unable to sense presence of CPU core
>>>> temperature or do Thermal management - including but not limited to
>>>> operating Fan speed.
>>>> Dom0 has to rely on other possible ways such as ipmi or BIOS which are
>>>> optionally available.
>>>>
>>>> From the patch description
>>>> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=72e038450d3d5de1a39f0cfa2d2b0f9b3d43c6c6
>>>> it seems that the change was introduced to not expose EAX(0x06h) to
>>>> unprivileged PV guests but nothing is said for Dom0 itself. I think
>>>> you already mentioned that the flag is hid from Dom0 as well
>>>> intentionally.
>>>>
>>>> So unless hypervisor wants to do thermal management of the CPU board,
>>>> it would inhibit Dom0's ability to do this function.
>>>
>>> That's likely what you want, on a Xen system dom0 is a special guest,
>>> but still a guest, so it's not feasible for a native dom0 driver to do
>>> power or temperature management without having Xen specific
>>> knowledge. For instance the load on dom0 doesn't match the actual
>>> load on the hardware.
>>>
>>> I think we had a very similar discussion at:
>>>
>>> https://marc.info/?l=xen-devel&m=156397696413230&w=2
>>>
>>> I would recommend reading the full thread and the
>>> conclusions/proposals.
>>>
>>> Roger.
>>
>> Thank Roger for the reference and conclusion. Repeating here for
>> having directed discussion.
>>
>>> It will involve looking into the Linux driver in order to make use of
>>> an hypercall instead of a rdmsr. I think it should be fine to expose
>>> the CPUID leaf to dom0 as long as reads are performed from the
>>> hypercall, in order to assure that Linux gets consistent values.
>>
>> The affected Linux driver in my case is coretemp.ko 
>> (drivers/hwmon/coretemp.c)
>>
>> It's init depends on checking presence of X86_FEATURE_DTHERM
>>
>>         /*
>>          * CPUID.06H.EAX[0] indicates whether the CPU has thermal
>>          * sensors. We check this bit only, all the early CPUs
>>          * without thermal sensors will be filtered out.
>>          */
>>
>> It seems to use below MSR
>> MSR_IA32_PACKAGE_THERM_STATUS
>> MSR_IA32_THERM_STATUS
>> MSR_IA32_TEMPERATURE_TARGET
>>
>> I'm not sure how can CPUID.06H.EAX[0] be read, should Xen provide a
>> hypercall interface to read this?
> 
> I think there's already some interface to read the raw cpuid policy,
> but maybe that's a domctl. Note that on PV executing a plain cpuid
> instruction without the Xen prefix will get you the native policy,
> albeit I won't rely on that since it will go away with PVH.

Nor would you see the real value in PV mode when the hardware
supports CPUID faulting (and you don't suppress this via
"dom0=no-cpuid-faulting").

> You will also need an interface to request Xen to execute rdmsr/wrmsr
> on specific pCPUs in order to get and set the thermal data.

As said elsewhere on this thread, we have such an interface already
(with a white listed set of MSRs).

Jan

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