[libvirt] [PATCH 6/6] util: Don't report CPU frequency for ARM hosts

[Daniel P. Berrange]

On Mon, Dec 11, 2017 at 06:14:54PM +0100, Andrea Bolognani wrote:
> On Mon, 2017-12-11 at 16:46 +0000, Daniel P. Berrange wrote:
> > On Mon, Dec 11, 2017 at 05:40:36PM +0100, Andrea Bolognani wrote:
> > > Some ARM platforms, such as the original Raspberry Pi, report the
> > > CPU frequency in the BogoMIPS field of /proc/cpuinfo, so libvirt
> > > parsed that field and returned it through its API.
> > > 
> > > However, not only many more boards don't report any value there,
> > > but several - including ARMv8-based server hardware, and even the
> > > more recent Raspberry Pi 3 - use this field as originally intended:
> > > to report the BogoMIPS value instead of the CPU frequency.
> > > 
> > > Since we have no way of detecting how the field is being used,
> > > it's better to report no information at all rather than something
> > > ludicrous like "your shiny 96-core aarch64 virtualization host's
> > > CPUs are running at a whopping 100 MHz".
> > 
> > Can we perhaps get useful freq data from sysfs instead ? I know my
> > x86 machines report freq there, but I'm unsure if that reporting
> > is x86-specific or not.
> 
> The plan is to start using dmidecode(8) to retrieve the CPU
> frequency, since AIUI it's already doing some work to locate the
> information and process it and it would be quite pointless to
> duplicate all that in libvirt. Plus we're already using the tool
> for other stuff.
> 
> I think that would only work on server-grade aarch64 hardware,
> though, because most other ARM hardware will simply not expose
> the information we need; even in that case, not reporting any
> CPU frequency is better than reporting a completely bogus value.
> 
> So basically reporting the actual CPU frequency when possible is
> in my TODO list[1], but I believe there's value in merging this
> series as-is since it already improves significantly on the
> status quo.

Sure, that's fine. I wasn't objecting to merging this series, just
wondering where we might find the useful data in future.


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