Hi Andrea, 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. As for calling lscpu, it does show a very good textual information, I will have a try using that as the source.
BR, Zhenyu On Mon, Mar 23, 2020 at 11:29 PM Andrea Bolognani <abolo...@redhat.com> wrote: > 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 > >