Propose to extend the capability of arm cpu driver

[Andrea Bolognani]

On Thu, 2020-03-05 at 17:23 +0800, Zhenyu Zheng wrote:
> Hi Andrea Bolognani!
> 
> Thank you very much for the reply and guide, they are very helpful.
> And we will treat as this as a long-term task to try to enrich ARM
> capabilities, both in libvirt and QEMU an other related projects.

That sounds good!

> As for the missing features, maybe I can do it one by one, start with
> simple ones, for example, the simplest feature: "using virsh
> capabilities" to show host cpu model, vendor and features is missing,
> this is quite simple and currently asked by our users.  I have a
> workable draft code that reads and parses /proc/cpuinfo for these
> informations, will thar work? or Libvirt prefers reads them directly
> from registers like currently done in x86 driver?

Parsing /proc/cpuinfo is fine - all architectures, including x86,
currently do that for at least some of the information.

The problem is that on many ARM machines the file doesn't contain a
whole lot of information, at least not in a form that's suitable for
end users: for example, on this machine that I have access to, all
it contains is

  processor       : 0
  BogoMIPS        : 200.00
  Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
  CPU implementer : 0x43
  CPU architecture: 8
  CPU variant     : 0x1
  CPU part        : 0x0a1
  CPU revision    : 1

which is definitely not as pretty as "Skylake-Client" or something :)

Another problem is that "virsh capabilities" on x86 will usually
report a CPU model that can then be used as a guest CPU[1], but that's
not really the case for ARM where CPU models are not as well defined
and QEMU definitely doesn't know about all of them.

Same goes with features: on x86 you can add or remove pretty much
any CPU feature from any CPU model, but on ARM QEMU only supports
toggling a small number of CPU features, and even the few CPU models
it knows about are hardly representative of what you'd find in the
average ARM server at this point.


[1] Even though you're not supposed to rely on that, and "virsh
    domcapabilities" is much better if that's what you're after.
-- 
Andrea Bolognani / Red Hat / Virtualization