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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.

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.

> Even if a hypercall is given, coretemp will have to be modified to
> separate MSR calls.

Not only this, keep in mind that dom0 vCPUs != pCPUs, so you will
likely need a way to tell coretemp about the real number of CPUs in
the system, which might not match the number of vCPUs dom0 has
assigned.

> 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

That's a Linux kernel question IMO, as a Xen developer I cannot tell
whether that's suitable or not since it's a detail of the Linux
implementation.

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

Seems feasible, but you will also have to check that lm_sensors
doesn't make any assumptions about the number of CPUs by reading
/proc/cpuinfo for example.

Roger.

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