[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |