On Wed, Jul 09, 2025 at 10:03:26AM +0200, Hector Cao wrote:
Hello,
This mail is a Request for Comment.
On recent Intel CPUs, some of the CPU features (mostly vmx-* subfeatures)
are listed and controlled
via the MSRs (Model Specific Registers) instead of the traditional CPUID
instruction method.
Right now, libvirt reads the MSR's values via /dev/cpu/*/cpu populated by
the msr kernel module.
src/cpu/cpu_x86.c:
...
/* This is best effort since there might be no way to read the MSR
* when we are not running as root. */
for (i = 0; i < nmsrs; i++) {
if (virHostCPUGetMSR(msrs[i], &msr) == 0) {
virCPUx86DataItem item = {
.type = VIR_CPU_X86_DATA_MSR,
.data.msr = {
...
There are 2 potential issues:
1) As stated in the source code comment above, MSR values read might fail
when libvirt is not run as root.
2) MSR values read might fail if the MSR kernel module is not loaded, this
is still the case in some of the Linux distros.
Neither of these should happen. virHostCPUGetMSR will try /dev/cpu/0/msr
and if that fails to be opened, it should always fallback to /dev/kvm.
Andrea Bolognani's proposal of an approach that could work:
1. try using the unprivileged KVM API is available (or maybe the
necessary information is exposed via QMP too?) like how QEMU does;
2. if that fails, try using the privileged /dev API;
Those steps need to be in the reverse order. /dev/kvm does not
give full MSR information - it only reports a subset of MSRs.
3. if that fails too, load the msr module and try again;
It seems like a modules-load file is simpler than having this manual
kmod load + repeat.
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 :|