Thanks alot for the reply!

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

As for this, these actually have some mapping rules:
https://developer.arm.com/docs/ddi0595/f/aarch64-system-registers/midr_el1  
what we will do is traslate these into human readable infomation, it
has already been done in the ``util-linux/lscpu`` tool:
https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu-arm.c
we can just do the same in our driver. You could try to download the latest
``util-linux`` in your arm server and have a try :)

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.

I have try to run the command on1) x86 server 2) ARM server without patch and
3) ARM server with my patch(please see attachments), the result seems pretty
much the same for this point, or maybe I missed your point here :)

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.

So this will be another thing to work on in QEMU/Libvirt in long-term, we will
look into this. Probably we can first display what we got from ``/proc/cpuinfo``
in the host field, this closes the gap between ARM and X86 a little bit, and
we will move the actual founctionality as you mentioned in the future.

P.S. my current patch is based on libvirt v5.5.0

Thanks again for the reply. 

On Fri, Mar 6, 2020 at 1:48 AM Andrea Bolognani <abologna@redhat.com> wrote:
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