On Fri, 2020-03-06 at 09:51 +0800, Zhenyu Zheng wrote:
> > 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 :)

I tried util-linux and lscpu reports reasonable information on at
least one (semi-recent) ARM machine I have access to. I have no idea
how well it would fare with older hardware.

Anyway, despite how impressive the results are, I'm pretty sure we
don't want to incorporate the same sort of translation table into
libvirt. Perhaps calling out to lscpu and parsing its output would
be a more acceptable solution...

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

The difference is that, on x86, you can mostly take the <host><cpu>
element from the capabilities XML and use it as <domain><cpu> in the
domain XML: in your case that would be

  <domain>
    <cpu>
      <model>Broadwell-IBRS</model>
      <topology sockets='1' cores='4' threads='2'/>
      <feature name='invtsc'/>
      <feature name='avx512cd'/>
      <feature name='avx512f'/>
      <feature name='mpx'/>
      <feature name='ssbd'/>
      <feature name='md-clear'/>
      <feature name='abm'/>
      <feature name='pdpe1gb'/>
      <feature name='hypervisor'/>
      <feature name='rdrand'/>
      <feature name='f16c'/>
      <feature name='osxsave'/>
      <feature name='ht'/>
      <feature name='ss'/>
      <feature name='vme'/>
    </cpu>

Again, this is not a good idea in general and you should rather look
at the domaincapabilities XML instead. So I don't think it's a
problem if the capabilities XML contains values that can't be used
for guests, but you have to ensure the same is not true when it comes
to the domcapabilities XML.

> > 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.

As long as none of this leaks into the domcapabilities XML, I don't
see a problem in exposing more information about the host.

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

That's a pretty old version. Please make sure your patch applies on
top of the master branch, or it won't be possible to accept it into
libvirt!

--
Andrea Bolognani / Red Hat / Virtualization