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

[Rishi <2rushikeshj@gmail.com>]

On Thu, Nov 21, 2019 at 7:26 PM Roger Pau Monné <roger.pau@citrix.com> 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@suse.com> 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?
Even if a hypercall is given, coretemp will have to be modified to
separate MSR calls.
Does having a pv temperature reader (pvcoretemp) altogether make
sense? This would have hypercall for DTS detection and XEN MSR reads
for values.
For compatibility, can it use the same sys path as that of coretemp.ko
to write thermal info?
/sys/devices/platform/pvcoretemp.0/hwmon/hwmon2/temp1_input

This will let lm_sensors lib (SNMP/CLI) interpret temps regularly.

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