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".
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
src/util/virhostcpu.c | 5 +----
tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected | 2 +-
tests/virhostcpudata/linux-armv6l-raspberrypi.expected | 2 +-
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c
index 3b478fc45..9bc213580 100644
--- a/src/util/virhostcpu.c
+++ b/src/util/virhostcpu.c
@@ -563,10 +563,7 @@ virHostCPUGetInfoParseCPUInfo(FILE *cpuinfo,
} else if (ARCH_IS_PPC(arch)) {
if (virHostCPUGetInfoParseCPUFrequency(line, "clock", mhz) < 0)
goto cleanup;
- } else if (ARCH_IS_ARM(arch)) {
- if (virHostCPUGetInfoParseCPUFrequency(line, "BogoMIPS", mhz) < 0)
- goto cleanup;
- } else if (ARCH_IS_S390(arch)) {
+ } else if (ARCH_IS_S390(arch) || ARCH_IS_ARM(arch)) {
/* No reasonable way to obtain CPU frequency */
} else {
VIR_WARN("Parser for /proc/cpuinfo needs to be adapted for your architecture");
diff --git a/tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected b/tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected
index 24ff0ea0b..6776aa6c2 100644
--- a/tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected
+++ b/tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected
@@ -1 +1 @@
-CPUs: 8/8, MHz: 100, Nodes: 1, Sockets: 1, Cores: 8, Threads: 1
+CPUs: 8/8, MHz: 0, Nodes: 1, Sockets: 1, Cores: 8, Threads: 1
diff --git a/tests/virhostcpudata/linux-armv6l-raspberrypi.expected b/tests/virhostcpudata/linux-armv6l-raspberrypi.expected
index 146bd073e..1c4c713d5 100644
--- a/tests/virhostcpudata/linux-armv6l-raspberrypi.expected
+++ b/tests/virhostcpudata/linux-armv6l-raspberrypi.expected
@@ -1 +1 @@
-CPUs: 1/1, MHz: 697, Nodes: 1, Sockets: 1, Cores: 1, Threads: 1
+CPUs: 1/1, MHz: 0, Nodes: 1, Sockets: 1, Cores: 1, Threads: 1
--
2.14.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Andrea Bolognani <abologna@redhat.com> [2017-12-11, 05:40PM +0100]:
> 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".
>
> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> ---
> src/util/virhostcpu.c | 5 +----
> tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected | 2 +-
> tests/virhostcpudata/linux-armv6l-raspberrypi.expected | 2 +-
> 3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c
> index 3b478fc45..9bc213580 100644
> --- a/src/util/virhostcpu.c
> +++ b/src/util/virhostcpu.c
> @@ -563,10 +563,7 @@ virHostCPUGetInfoParseCPUInfo(FILE *cpuinfo,
> } else if (ARCH_IS_PPC(arch)) {
> if (virHostCPUGetInfoParseCPUFrequency(line, "clock", mhz) < 0)
> goto cleanup;
> - } else if (ARCH_IS_ARM(arch)) {
> - if (virHostCPUGetInfoParseCPUFrequency(line, "BogoMIPS", mhz) < 0)
> - goto cleanup;
> - } else if (ARCH_IS_S390(arch)) {
> + } else if (ARCH_IS_S390(arch) || ARCH_IS_ARM(arch)) {
> /* No reasonable way to obtain CPU frequency */
> } else {
> VIR_WARN("Parser for /proc/cpuinfo needs to be adapted for your architecture");
I'm a bit confused now. If we have a not supported arch, will this
warning not get issued for every line in /proc/cpuinfo? It's the same
for the original code.
> diff --git a/tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected b/tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected
> index 24ff0ea0b..6776aa6c2 100644
> --- a/tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected
> +++ b/tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected
> @@ -1 +1 @@
> -CPUs: 8/8, MHz: 100, Nodes: 1, Sockets: 1, Cores: 8, Threads: 1
> +CPUs: 8/8, MHz: 0, Nodes: 1, Sockets: 1, Cores: 8, Threads: 1
> diff --git a/tests/virhostcpudata/linux-armv6l-raspberrypi.expected b/tests/virhostcpudata/linux-armv6l-raspberrypi.expected
> index 146bd073e..1c4c713d5 100644
> --- a/tests/virhostcpudata/linux-armv6l-raspberrypi.expected
> +++ b/tests/virhostcpudata/linux-armv6l-raspberrypi.expected
> @@ -1 +1 @@
> -CPUs: 1/1, MHz: 697, Nodes: 1, Sockets: 1, Cores: 1, Threads: 1
> +CPUs: 1/1, MHz: 0, Nodes: 1, Sockets: 1, Cores: 1, Threads: 1
> --
> 2.14.3
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
IBM Systems
Linux on z Systems & Virtualization Development
------------------------------------------------------------------------
IBM Deutschland
Schönaicher Str. 220
71032 Böblingen
Phone: +49 7031 16 1819
E-Mail: bwalk@de.ibm.com
------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, 2017-12-13 at 08:45 +0100, Bjoern Walk wrote:
> > @@ -563,10 +563,7 @@ virHostCPUGetInfoParseCPUInfo(FILE *cpuinfo,
> > } else if (ARCH_IS_PPC(arch)) {
> > if (virHostCPUGetInfoParseCPUFrequency(line, "clock", mhz) < 0)
> > goto cleanup;
> > - } else if (ARCH_IS_ARM(arch)) {
> > - if (virHostCPUGetInfoParseCPUFrequency(line, "BogoMIPS", mhz) < 0)
> > - goto cleanup;
> > - } else if (ARCH_IS_S390(arch)) {
> > + } else if (ARCH_IS_S390(arch) || ARCH_IS_ARM(arch)) {
> > /* No reasonable way to obtain CPU frequency */
> > } else {
> > VIR_WARN("Parser for /proc/cpuinfo needs to be adapted for your architecture");
>
> I'm a bit confused now. If we have a not supported arch, will this
> warning not get issued for every line in /proc/cpuinfo? It's the same
> for the original code.
Yeah, it would look that way :)
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1206353 -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.