On Tue, Feb 20, 2024 at 03:00:56PM +0100, Anthony Harivel wrote: > Daniel P. Berrangé, Jan 29, 2024 at 20:29: > > On Thu, Jan 25, 2024 at 08:22:14AM +0100, Anthony Harivel wrote: > > > diff --git a/docs/specs/rapl-msr.rst b/docs/specs/rapl-msr.rst > > > new file mode 100644 > > > index 000000000000..04d27c198fc0 > > > --- /dev/null > > > +++ b/docs/specs/rapl-msr.rst > > > @@ -0,0 +1,133 @@ > > > +================ > > > +RAPL MSR support > > > +================ > > > > > + > > > +Current Limitations > > > +------------------- > > > + > > > +- Works only on Intel host CPUs because AMD CPUs are using different MSR > > > + addresses. > > > > The privileged helper program is validating an allow list of MSRs. > > > > If those MSRs are only correct on Intel hosts, then the validation > > is incomplete, and it could be allowing unprivileged processes on > > AMD hosts to access forbidden MSRS whose address happen to clash > > with the Intel RAPL MSRs. > > > > IOW, the privileged helper needs to call cpuid() and validate that > > the current host vendor is Intel. > > > > I suspect we also need a feature check of some kind to validate > > that the intel processor supports this features, since old ones > > definitely didn't, and we shouldn't assume all future ones will > > either. > > > > To validate that the processor supports the RAPL feature I propose > to check this on the Host: > > $ cat /sys/class/powercap/intel-rapl/enabled > 1 > > > The only down side is that INTEL RAPL drivers needs to be > mounted then. We don't need it because we directly read the MSRs.
Awkward. I've looked around in the kernel drivers and didn't uncover any better option than this. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
