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