Propose to extend the capability of arm cpu driver

[Zhenyu Zheng]

Hi Andrea Bolognani!

Thank you very much for the reply and guide, they are very helpful. And we
will treat
as this as a long-term task to try to enrich ARM capabilities, both in
libvirt and QEMU
an other related projects.

As for the missing features, maybe I can do it one by one, start with
simple ones,
for example, the simplest feature: "using virsh capabilities" to show host
cpu model,
vendor and features is missing, this is quite simple and currently asked by
our users.
I have a workable draft code that reads and parses /proc/cpuinfo for these
informations,
will thar work? or Libvirt prefers reads them directly from registers like
currently done
in x86 driver?

Thanks again,

Kevin Zheng

On Wed, Mar 4, 2020 at 8:46 PM Andrea Bolognani <abologna at redhat.com> wrote:

> On Wed, 2020-03-04 at 15:15 +0800, Zhenyu Zheng wrote:
> > Hello Libvirt,
> >
> > With more and more ARM servers on the market and increasing amount of
> > users, we got reported alot that Libvirt cannot provide as much
> > function on ARM platform as on other platforms(mainly x86), some basic
> > founctions are missing, such as showing cpu model details and features
> > using ``virsh capabilities``, comparing cpus etc.
> >
> > So I would like to propose to extend the capability of ARM cpu driver.
> > Since I'm quite new here, I searched through the mailing list and did
> > not find much information on this, so I would like to know that will
> > this be something that I could work on?
>
> In general terms, any gaps between what is possible on x86 and what
> is possible on ARM are considered bugs and anyone interested in
> addressing them is very much welcome!
>
> On the topic of CPUs specifically, the limitations have been known
> for a long time but there are significant obstacles to solving them:
>
>   a) QEMU does not have named models for ARM CPUs at this point,
>      which makes comparing different guest CPUs basically impossible;
>
>   b) the Linux kernel does not report information about eg. CPU
>      frequencly consistently;
>
>   c) historically, ARM server vendors have included incorrect or
>      incomplete information in their products' ACPI and DMI tables.
>
> b) is, I believe, mostly a consequence of c); the latter is also the
> reason why libvirt can't really trust this information even if they
> happen to be available on a particular machine.
>
> Addressing a) is a long-term to do item for QEMU developers, and it
> has seen some progress lately; b) can only be addressed by hardware
> vendors.
>
> --
> Andrea Bolognani / Red Hat / Virtualization
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200305/3731bf79/attachment-0001.htm>