[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 21.11.2019 14:39, Rishi wrote:
> The reasoning to have EAX(0x06h) exposed to Dom0 is for Thermal and
> Power management.

I understand this.

> 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.

But you don't seem to understand that this is, from a layering
perspective, not Dom0's job. (As per the other reply sent a
moment ago, it can be made work, but it's not as simple as you
appear to think.) In principle - repeating this just another
time - it's Xen's job to handle this.

> 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.
> 
> What is an alternative way for coretemp kernel module to detect
> "DTHERM" processor flag and/or proceed for safe reading of MSR to do
> further temperature value reads?

Introduction of a proper interface between Xen and Dom0 by which
Xen becomes aware of this part of CPU management getting delegated
to Dom0.

Jan

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.