Re: [RFC] x86 Host CPU features detection by MSRs

On Wed, Jul 9, 2025 at 12:01 PM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: > On Wed, Jul 09, 2025 at 05:58:03AM -0400, Andrea Bolognani wrote: > > On Wed, Jul 09, 2025 at 09:53:40AM +0100, Daniel P. Berrangé via Devel > wrote: > > > On Wed, Jul 09, 2025 at 10:29:32AM +0200, Hector Cao wrote: > > > > > > 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. > > > > Well, we can perform the load unconditionally too. I was concerned > > that doing so would result in a failure on Fedora and other distros > > that have msr built-in, but I just tried and it seems that modprobe > > is smart enough to handle that scenario gracefully. > > > > The other question is what to do if we can't read the msr > > information. It seems that right now we report the incorrect CPU > > model, which is obviously not ideal. Raising an error would probably > > be better, but I'm not sure whether the APIs are really designed in a > > way that makes that possible. > > IMHO an inability to read the msr info is a distro integration bug. > > Given the /dev/kvm fallback, the most common failure scenario will > be on distros where /dev/kvm is restricted access. At that point > though you can't run KVM enabled guests anyway, so the MSR problem > is the least of your worries, as the info obtanied from MSRs is > not especially relevant to TCG usage. > > Hello Daniel, You are right about the fallback. I did the verification on an Intel Granite Rapids (GNR) platform and the fallback to /dev/kvm works for me (under the condition that this issue is fixed : https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/XN... ) However, since you mentioned that /dev/kvm might be incomplete for MSR features (depending on the kernel version), do you consider it still useful to try to load the MSR module ? If that is the case, I can work on submitting something for that.