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 :|