<div dir="ltr">Hi Andrea,<div><br></div><div>Thanks again for the reply, I've already re-implement the codes on the master branch last week and trying to get ready to post it in the mailing list.</div><div>As for calling lscpu, it does show a very good textual information, I will have a try using that as the source.</div><div></div><div><br></div><div>BR,</div><div><br></div><div>Zhenyu</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 23, 2020 at 11:29 PM Andrea Bolognani <<a href="mailto:abologna@redhat.com">abologna@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2020-03-06 at 09:51 +0800, Zhenyu Zheng wrote:<br>
> > The problem is that on many ARM machines the file doesn't contain a<br>
> > whole lot of information, at least not in a form that's suitable for<br>
> > end users: for example, on this machine that I have access to, all<br>
> > it contains is<br>
> >   processor       : 0<br>
> >   BogoMIPS        : 200.00<br>
> >   Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid<br>
> >   CPU implementer : 0x43<br>
> >   CPU architecture: 8<br>
> >   CPU variant     : 0x1<br>
> >   CPU part        : 0x0a1<br>
> >   CPU revision    : 1<br>
> > which is definitely not as pretty as "Skylake-Client" or something :)<br>
> <br>
> As for this, these actually have some mapping rules:<br>
> <a href="https://developer.arm.com/docs/ddi0595/f/aarch64-system-registers/midr_el1" rel="noreferrer" target="_blank">https://developer.arm.com/docs/ddi0595/f/aarch64-system-registers/midr_el1</a>  <br>
> what we will do is traslate these into human readable infomation, it<br>
> has already been done in the ``util-linux/lscpu`` tool:<br>
> <a href="https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu-arm.c" rel="noreferrer" target="_blank">https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu-arm.c</a><br>
> we can just do the same in our driver. You could try to download the latest<br>
> ``util-linux`` in your arm server and have a try :)<br>
<br>
I tried util-linux and lscpu reports reasonable information on at<br>
least one (semi-recent) ARM machine I have access to. I have no idea<br>
how well it would fare with older hardware.<br>
<br>
Anyway, despite how impressive the results are, I'm pretty sure we<br>
don't want to incorporate the same sort of translation table into<br>
libvirt. Perhaps calling out to lscpu and parsing its output would<br>
be a more acceptable solution...<br>
<br>
> > Another problem is that "virsh capabilities" on x86 will usually<br>
> > report a CPU model that can then be used as a guest CPU[1], but that's<br>
> > not really the case for ARM where CPU models are not as well defined<br>
> > and QEMU definitely doesn't know about all of them.<br>
> <br>
> I have try to run the command on1) x86 server 2) ARM server without patch and<br>
> 3) ARM server with my patch(please see attachments), the result seems pretty<br>
> much the same for this point, or maybe I missed your point here :)<br>
<br>
The difference is that, on x86, you can mostly take the <host><cpu><br>
element from the capabilities XML and use it as <domain><cpu> in the<br>
domain XML: in your case that would be<br>
<br>
  <domain><br>
    <cpu><br>
      <model>Broadwell-IBRS</model><br>
      <topology sockets='1' cores='4' threads='2'/><br>
      <feature name='invtsc'/><br>
      <feature name='avx512cd'/><br>
      <feature name='avx512f'/><br>
      <feature name='mpx'/><br>
      <feature name='ssbd'/><br>
      <feature name='md-clear'/><br>
      <feature name='abm'/><br>
      <feature name='pdpe1gb'/><br>
      <feature name='hypervisor'/><br>
      <feature name='rdrand'/><br>
      <feature name='f16c'/><br>
      <feature name='osxsave'/><br>
      <feature name='ht'/><br>
      <feature name='ss'/><br>
      <feature name='vme'/><br>
    </cpu><br>
<br>
Again, this is not a good idea in general and you should rather look<br>
at the domaincapabilities XML instead. So I don't think it's a<br>
problem if the capabilities XML contains values that can't be used<br>
for guests, but you have to ensure the same is not true when it comes<br>
to the domcapabilities XML.<br>
<br>
> > Same goes with features: on x86 you can add or remove pretty much<br>
> > any CPU feature from any CPU model, but on ARM QEMU only supports<br>
> > toggling a small number of CPU features, and even the few CPU models<br>
> > it knows about are hardly representative of what you'd find in the<br>
> > average ARM server at this point.<br>
> <br>
> So this will be another thing to work on in QEMU/Libvirt in long-term, we will<br>
> look into this. Probably we can first display what we got from ``/proc/cpuinfo``<br>
> in the host field, this closes the gap between ARM and X86 a little bit, and<br>
> we will move the actual founctionality as you mentioned in the future.<br>
<br>
As long as none of this leaks into the domcapabilities XML, I don't<br>
see a problem in exposing more information about the host.<br>
<br>
> P.S. my current patch is based on libvirt v5.5.0<br>
<br>
That's a pretty old version. Please make sure your patch applies on<br>
top of the master branch, or it won't be possible to accept it into<br>
libvirt!<br>
<br>
-- <br>
Andrea Bolognani / Red Hat / Virtualization<br>
<br>
</blockquote></div>