<div dir="ltr">Thanks alot for the reply!<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 :)</blockquote><div><br></div><div>As for this, these actually have some mapping rules:</div><div><a href="https://developer.arm.com/docs/ddi0595/f/aarch64-system-registers/midr_el1">https://developer.arm.com/docs/ddi0595/f/aarch64-system-registers/midr_el1</a> <br></div><div>what we will do is traslate these into human readable infomation, it</div><div>has already been done in the ``util-linux/lscpu`` tool:</div><div><a href="https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu-arm.c">https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu-arm.c</a></div><div>we can just do the same in our driver. You could try to download the latest</div><div>``util-linux`` in your arm server and have a try :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>I have try to run the command on1) x86 server 2) ARM server without patch and</div><div>3) ARM server with my patch(please see attachments), the result seems pretty</div><div>much the same for this point, or maybe I missed your point here :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>So this will be another thing to work on in QEMU/Libvirt in long-term, we will</div><div>look into this. Probably we can first display what we got from ``/proc/cpuinfo``</div><div>in the host field, this closes the gap between ARM and X86 a little bit, and</div><div>we will move the actual founctionality as you mentioned in the future.</div><div><br></div><div>P.S. my current patch is based on libvirt v5.5.0</div><div><br></div><div>Thanks again for the reply. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 6, 2020 at 1:48 AM 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 Thu, 2020-03-05 at 17:23 +0800, Zhenyu Zheng wrote:<br>
> Hi Andrea Bolognani!<br>
> <br>
> Thank you very much for the reply and guide, they are very helpful.<br>
> And we will treat as this as a long-term task to try to enrich ARM<br>
> capabilities, both in libvirt and QEMU an other related projects.<br>
<br>
That sounds good!<br>
<br>
> As for the missing features, maybe I can do it one by one, start with<br>
> simple ones, for example, the simplest feature: "using virsh<br>
> capabilities" to show host cpu model, vendor and features is missing,<br>
> this is quite simple and currently asked by our users. I have a<br>
> workable draft code that reads and parses /proc/cpuinfo for these<br>
> informations, will thar work? or Libvirt prefers reads them directly<br>
> from registers like currently done in x86 driver?<br>
<br>
Parsing /proc/cpuinfo is fine - all architectures, including x86,<br>
currently do that for at least some of the information.<br>
<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>
<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>
<br>
which is definitely not as pretty as "Skylake-Client" or something :)<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>
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>
<br>
[1] Even though you're not supposed to rely on that, and "virsh<br>
domcapabilities" is much better if that's what you're after.<br>
-- <br>
Andrea Bolognani / Red Hat / Virtualization<br>
<br>
</blockquote></div>