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