On Fri, Jul 25, 2025 at 11:46:54AM +0200, Hector Cao wrote: > On Fri, Jul 25, 2025 at 11:22 AM Daniel P. Berrangé <berra...@redhat.com> > wrote: > > > On Wed, Jul 23, 2025 at 08:15:25PM +0200, Hector Cao wrote: > > > On Wed, Jul 9, 2025 at 12:01 PM Daniel P. Berrangé <berra...@redhat.com> > > > 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/XNOHU7PODTZVCX7ZQ2PBM7DRQRG2D6C7/ > > > ) > > > > > > 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. > > > > I don't think we need code todo that, but if a modules-load file can do > > that, we could ship one. > > > > I see and agree > > What do you think of this design: > 1) Create a file msr.conf inside src/util/modules-load.d/ > 2) Modify src/util/meson.build to install this file to /etc/modules-load.d/ > > Optional: > - Do you think it is necessary to add the configuration option to enable > this modules-load file installation ?
We should probably have a meson_options.txt entry as some distros have it as a built-in, so it would be wierd to see a file installed to load it. > - Do you think it is necessary to modify virt-host-validate to check if the > msr module is loaded I don't need to check the module directly, but we could do a simple path check for the MSR device node and add "load msr.ko" as a hint on failure 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 :|
