[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] CPU frequency throttling based on the temperature
-- 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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |