Re: [Libguestfs] [PATCH] p2v: Use lscpu instead of libvirt to get CPU information.
On Fri, Mar 24, 2017 at 11:39:52AM +0100, Pino Toscano wrote:
On Thursday, 23 March 2017 15:31:36 CET Richard W.M. Jones wrote:
> Don't get the CPU information from libvirt, because including libvirt
> and all dependencies in the virt-p2v ISO bloats everything.
>
> Instead get most of the information we need from the util-linux
> program 'lscpu'.
>
> Unfortunately the CPU model cannot be retrieved.
Theoretically, at least for Intel CPUs it could be mapped from the
"Model" field; there's a table on the intel website:
https://software.intel.com/en-us/articles/intel-architecture-and-processo...
although it is not up-to-date...
To map it into a libvirt model (which is ultimately what we want) we'd
have to use /usr/share/libvirt/cpu_map.xml, which involves some
complicated mapping from the flags information. It's a shame this
code is buried in libvirt and not available separately.
> - while (errno = 0, (len = getline (&flag, &buflen,
fp)) != -1) {
> - if (len > 0 && flag[len-1] == '\n')
> - flag[len-1] = '\0';
> -
> - if (STREQ (flag, "acpi"))
> - cpu->acpi = 1;
> - else if (STREQ (flag, "apic"))
> - cpu->apic = 1;
> - else if (STREQ (flag, "pae"))
> - cpu->pae = 1;
> + ret = malloc (sizeof (char *));
> + if (ret == NULL) error (EXIT_FAILURE, errno, "malloc");
> + ret[0] = NULL;
> +
> + while (errno = 0, (len = getline (&line, &buflen, fp)) != -1) {
I know it was already in the previous version, but why the need to
reset errno for each iteration? IIRC the return code of getline can
be trusted to know when an error happened.
I believe it's because getline returns -1 on EOF as well as error, and
I want to distinguish the two cases (although I have to admit I just
copied it from the old code).
> + if (vendor) {
> + /* Note this mapping comes from /usr/share/libvirt/cpu_map.xml */
> + if (STREQ (vendor, "GenuineIntel"))
> + cpu->vendor = strdup ("Intel");
> + else if (STREQ (vendor, "AuthenticAMD"))
> + cpu->vendor = strdup ("AMD");
> + /* Currently aarch64 lscpu has no Vendor ID XXX. */
> + }
How do tools such as dmidecode (use `dmidecode --type 4` to get only
the processor information) or lshw (`lshw -class processor`) behave on
aarch64?
- dmidecode does not have a machine parseable output, but does provide
the CPU model ID
- lshw has both XML and JSON output, but it does not seem to provide the
CPU model ID
The rest of the changes would look fine otherwise.
I think as above that we need the libvirt CPU model specifically, and
not just any old CPU model. On my x86_64 laptop, dmidecode returns
"Core i7" (not "Broadwell").
On aarch64 it depends on whether we're using ACPI or DT for boot.
For ACPI, dmidecode information is available, but inaccurate
("Family: ARM" ... hmm). lshw has the same info as /proc/cpuinfo
which is useless for us.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v