Re: [Xen-devel] CPU frequency throttling based on the temperature

["Fredy P." <fredy.pulido@savoirfairelinux.com>]

-- 
Fredy Pulido,
Consultant en logiciel libre
Infrastructure, Infonuagique et architecture de systèmes
Savoir-faire Linux, Montréal, Qc
Bureau : (+ 1) 514 276-5468 p.410 

Message de confidentialité :
Ce courriel (de même que les fichiers joints) est strictement réservé à
l'usage de la personne ou de l'entité à qui il est adressé et peut
contenir de l'information privilégiée et confidentielle.
Toute divulgation, distribution ou copie de ce courriel est strictement
prohibée.
Si vous avez reçu ce courriel par erreur, veuillez nous en aviser sur-
le-champ, détruire toutes les copies et le supprimer de votre système
informatique.

On Thu, 2019-07-25 at 16:07 +0200, Roger Pau Monné wrote:
> On Thu, Jul 25, 2019 at 01:43:34PM +0000, Jan Beulich wrote:
> > On 25.07.2019 15:13, Roger Pau Monné  wrote:
> > > On Thu, Jul 25, 2019 at 12:54:46PM +0000, Jan Beulich wrote:
> > > > On 25.07.2019 14:44,  Fredy P.  wrote:
> > > > > On Wed, 2019-07-24 at 17:41 +0200, Roger Pau Monné wrote:
> > > > > > > > What hardware interface does thermald (or the driver in
> > > > > > > > Linux if
> > > > > > > > there's one) use to get the temperature data?
> > > > > 
> > > > > In our initial POC using Xen 4.8.x we where using Linux
> > > > > coretemp driver
> > > > > reading by example /class/sys/hwmon/hwmon0/temp3_input but it
> > > > > got
> > > > > deprecated at commit 72e038450d3d5de1a39f0cfa2d2b0f9b3d43c6c6
> > > > 
> > > > Hmm, I wouldn't call this deprecation, but a regression. I
> > > > would
> > > > say we want to re-expose this leaf to Dom0, the more that the
> > > > commit also only mentions unprivileged domains. Andrew?
> > > 
> > > AFAICT from the documents provided by Fredy the temperature is
> > > read
> > > from a MSR that reports the current temperature of the core on
> > > which
> > > the MSR is read from. When running on Xen this will only work
> > > correctly if dom0 is given the same vCPUs as pCPUs and those are
> > > identity pinned.
> > > 
> > > Not sure how common this MSR interface is in order to read
> > > thermal
> > > values, if the interface it's common maybe it's something that
> > > could
> > > be implemented in Xen, and exported somehow to dom0, maybe using
> > > sysctl?
> > > 
> > > Or else having an hypercall that allows dom0 to request Xen to
> > > execute
> > > MSR read/writes on a given pCPU.
> > 
> > This would look to require just a small extension to
> > XEN_RESOURCE_OP_MSR_READ. Question is whether the Linux driver
> > maintainers would accept a change using this Xen-specific
> > alternative access mechanism (in whatever shape).
> 
> Right, there's also the fact that all pCPUs should be reported in the
> thermal driver, while dom0 might have less vCPUs than pCPUs on the
> system.
> 
> Do you think you can take a look into this Fredy?

I think I can but will takes long, short history I'm "just a sysadmin
doing a security update" then I'll try to find if some one of the guys
that wrote low level code to help me with this.

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



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