Bug 1426162

Could you please provide more data? Libvirtd debug log would be helpful. On my machine it works as expected so I suspect it's a hardware specific issue.

So I found a box where this reproduces. /proc/cpuinfo of that box looks like:

processor	: 0
BogoMIPS	: 100.00
Features	: fp asimd evtstrm
CPU implementer	: 0x50
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0x000
CPU revision	: 1

processor	: 1
BogoMIPS	: 100.00
Features	: fp asimd evtstrm
CPU implementer	: 0x50
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0x000
CPU revision	: 1

[...]

In such case there is no CPU name or other data to report thus libvirt does not report anything. I don't think there's anything useful to report here in this case.

If your machine contains useful data in /proc/cpuinfo please reopen this BZ.

/proc/cpuinfo looks different on AArch64 machines vs. x86 machines, but they do have SMBIOS. What information is libvirt expecting? It may be missing, or it may just be in a different place. Is libvirt even attempting to extract the SMBIOS tables? There's plenty of info in them on my mustang, shown with dmidecode. I'd prefer we reopen this bug and attempt to get sysinfo to output more useful info on these machines.

The current code in libvirt for ARM ignores SMBIOS since historically arm7 / early aarch64 didn't have that available. We need to fix that to make it use SMBIOS if available.

This may not be possible for 7.4 due to AArch64 servers still not having much info in /proc/cpuinfo and also not having complete SMBIOS tables. See bug 1430987 for a similar bug, which is also blocked on the host needing to provide the information libvirt needs.

We need to get /proc/cpuinfo to say useful things too. I'm stirring up.

BTW, we would really rather have information provided in a sane format in sysfs, with the one attribute per file model.  The /proc/cpuinfo file is an horrible thing to deal with due to having to hand write parsers for it, and its content being different on every architecture.

(In reply to Daniel Berrange from comment #9)
> BTW, we would really rather have information provided in a sane format in
> sysfs, with the one attribute per file model.  The /proc/cpuinfo file is an
> horrible thing to deal with due to having to hand write parsers for it, and
> its content being different on every architecture.

If an aarch64 system has implemented CPPC, the cpufreq directory is populated, so you can get things like max frequency:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 
3200000

Or you can get cpuinfo_max_frequency, instead (usually identical).

There are a couple of older platforms that do not implement CPPC, but would also not likely be used as host machines in a production environment.

Is this sufficient?  Others have asked for this to be in /proc/cpuinfo, also, so that probably needs to be added regardless.

Patches posted upstream:

https://www.redhat.com/archives/libvir-list/2019-May/msg00221.html

v2:

https://www.redhat.com/archives/libvir-list/2019-May/msg00244.html

Test data (prerequisite for merging) posted upstream.

  https://www.redhat.com/archives/libvir-list/2019-May/msg00869.html

Pushed upstream:

ec6ce6363a virSysinfoReadARM: Try reading DMI table
ac61c9cfc3 virsysinfo: Rename virSysinfoReadX86 to virSysinfoReadDMI
667a373526 tests: Add aarch64-gigabyte sysinfo test case
43bc35ac1a tests: Tweak x86 sysinfo test case

v5.4.0-32-gec6ce6363a

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3723