[Libguestfs] [PATCH] p2v: Use lscpu instead of libvirt to get CPU information.

[Richard W.M. Jones]

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-processor-identification-with-cpuid-model-and-family-numbers
> 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