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@xxxxxxxxxx> 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
