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). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
