On Wed, Aug 12, 2026 at 10:36:51AM +0200, Roman Bogorodskiy wrote: > Tiago Espinha Gasiba wrote: > > > From: Tiago Gasiba <[email protected]> > > > > From: Tiago Gasiba <[email protected]> > > > > Signed-off-by: Tiago Espinha Gasiba <[email protected]> > > --- > > src/util/virhostcpu.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c > > index f2b25e940b..b602592fb7 100644 > > --- a/src/util/virhostcpu.c > > +++ b/src/util/virhostcpu.c > > @@ -993,8 +993,8 @@ virHostCPUGetInfo(virArch hostarch G_GNUC_UNUSED, > > > > if (sysctlbyname("dev.cpu.0.freq", &cpu_freq, &cpu_freq_len, NULL, 0) > > < 0) { > > if (sysctlbyname("hw.clockrate", &cpu_freq, &cpu_freq_len, NULL, > > 0) < 0) { > > - virReportSystemError(errno, "%s", _("cannot obtain CPU freq")); > > - return -1; > > + VIR_WARN("cannot obtain CPU freq, setting to 0"); > > + cpu_freq = 0; > > } > > } > > > > Merge request provides more details on this issue: > https://gitlab.com/libvirt/libvirt/-/merge_requests/553. > > Apparently, calling virReportSystemError() from virHostCPUGetInfo() is > not desired. This function is used by drivers to implement > virNodeGetInfo(), so raising error here prevents from using the > virNodeGetInfo() API. This leads to other issues, e.g. virt-manager > fails to connect to the driver if virNodeGetInfo() errors out. > > Falling back to CPU frequency 0 if it cannot be obtained looks like a > sane option. In theory, it could cause division by 0, but in practice it > does not seem that cpu frequency could be used as a divisor. > > virt-manager does not seem to actually use CPU frequency it gets from > virNodeGetInfo(). And virsh prints out CPU frequency only if it is not > zero. > > Having that said: > > Reviewed-by: Roman Bogorodskiy <[email protected]> > > I'll wait a few days before pushing in case if anyone has objects to > this fallback behavior.
Fine to push, but just downgrade the log message to VIR_DEBUG. We don't want to use VIR_WARN in scenarios which are "expected behaviour" as that pollutes logs for users who have that (otherwise acceptable) deployment scenario. Reviewed-by: Daniel P. Berrangé <[email protected]> With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
