Description of problem: virsh sysinfo can not show correct system information Version-Release number of selected component (if applicable): libvirt-3.0.0-1.el7 How reproducible: 100% Steps to Reproduce: 1.virsh sysinfo 2. 3. Actual results: <sysinfo type='smbios'/> Expected results: have bios, system, processor and memory_device informations Additional info:
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