[PATCH 5/5] cpu: Introduce getHost supoort for ARM

Zhenyu Zheng zhengzhenyulixi at gmail.com
Thu Apr 2 09:11:06 UTC 2020


Hi Daniel,

Thanks for the review and tips, I've done some learning and finally found
the way to read and parse vendor_id, part_id and cpu flags of an ARM
CPU directly from registers just like what has been done in X86 drivers.
And I've uploaded a V2 patch for these.

BR,

Zhenyu Zhengh

On Mon, Mar 30, 2020 at 8:27 PM Daniel P. Berrangé <berrange at redhat.com>
wrote:

> Re-adding libvir-list to the CC line.
>
> On Mon, Mar 30, 2020 at 08:20:44PM +0800, Zhenyu Zheng wrote:
> > Hi, yes, I think we can do that using  inline assembly, I can check it
> out
> > if you think it is a better solution,
> > do you have any suggestions for the features(cpu flags) part? It seems
> that
> > ARM does not have a location/register
> > that holds all the flags, seems that we have to query alot of different
> > registers to check for features, which could
> > be quite messy.
>
> Perhaps there is a way to record the location/register info in the XML
> against each feature name, so that the code itself can stay simple and
> just be driven from the metadata ?
>
> I'm not familiar enough with Arm to know how feasiable this is though,
> so will have to leave that to others to give an opinion.
>
> >
> > On Mon, Mar 30, 2020 at 8:01 PM Daniel P. Berrangé <berrange at redhat.com>
> > wrote:
> >
> > > On Mon, Mar 30, 2020 at 07:32:36PM +0800, Zhenyu Zheng wrote:
> > > > Hi Daniel,
> > > >
> > > > Thanks for thre review and reply, my first implementation was going
> to
> > > > gather data from /proc/cpuinfo, but unlike X86, we can only get this
> kind
> > > > of info:
> > > >
> > > >   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
> > > >
> > > > so we have to perform some translation to perform human readable
> > > > information, and I mentioned that 'lscpu' has done that too. So
> Andrea
> > > > Bolognani
> > > > suggested that maybe we can use it directly, to avoid re-implement
> the
> > > > translation. Here is the discussion:
> > > > https://www.redhat.com/archives/libvir-list/2020-March/msg00812.html
> > >
> > > On x86 we get majority of info straight from calling the CPUID
> instruction,
> > > not /proc/cpuinfo, and use our XML data files in src/cpu_map to
> translate
> > > things into human readable names.  I see you're adding XML data files
> > > with names in the earlier patches. Is it possible to add the hex values
> > > for the CPU implementer/architecture/variant/part to these XML files so
> > > we can directly map them in libvirt, in the same way we do for x86
>
> Regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200402/c5f9cac5/attachment-0001.htm>


More information about the libvir-list mailing list