[libvirt] [Resending][PATCH v2 2/2] x86: Allow sysinfo to fall back on /proc/cpuinfo if demidecode is absent

[Daniel Veillard]

On Tue, Mar 13, 2012 at 11:10:16AM +0530, Prerna Saxena wrote:
> From: Prerna Saxena <prerna at linux.vnet.ibm.com>
> Date: Tue, 13 Mar 2012 15:33:43 +0530
> Subject: [PATCH 2/2] Sysinfo : Allow x86 to fetch sysinfo from 
>  /proc/cpuinfo in the event 'dmidecode' is absent in the system.
> 
> Until now, libvirt on x86 flags an error message if dmidecode is not
> found. With this patch, the following is a sample output on x86 when
> dmidecode is absent:
> 
> virsh # sysinfo
> <sysinfo type='smbios'>
>   <processor>
>     <entry name='socket_destination'>0</entry>
>     <entry name='type'>Intel(R) Xeon(R) CPU X5570  @ 2.93GHz</entry>
>     <entry name='family'>6</entry>
>     <entry name='manufacturer'>GenuineIntel</entry>
>   </processor>
>   <processor>
>     <entry name='socket_destination'>1</entry>
>     <entry name='type'>Intel(R) Xeon(R) CPU X5570  @ 2.93GHz</entry>
>     <entry name='family'>6</entry>
>     <entry name='manufacturer'>GenuineIntel</entry>
>   </processor>
>   ... (listing for all online CPUs)
> </sysinfo>
> 
> Based on suggestion from Eric:
> (http://www.redhat.com/archives/libvir-list/2012-February/msg00509.html)
> 
> Acked-by: Daniel P Berrange <berrange at redhat.com>
> Signed-off-by: Prerna Saxena <prerna at linux.vnet.ibm.com>
> ---
>  src/util/sysinfo.c |   97 +++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 files changed, 93 insertions(+), 4 deletions(-)
> 
> diff --git a/src/util/sysinfo.c b/src/util/sysinfo.c
> index 78efc32..290b69f 100644
> --- a/src/util/sysinfo.c
> +++ b/src/util/sysinfo.c
> @@ -598,6 +598,98 @@ no_memory:
>      return -1;
>  }
>  
> +/* If a call to 'dmidecode' fails,
> + * extract basic sysinfo from /proc/cpuinfo */
[...]
>  virSysinfoDefPtr
>  virSysinfoRead(void) {
>      char *path;
> @@ -607,10 +699,7 @@ virSysinfoRead(void) {
>  
>      path = virFindFileInPath(SYSINFO_SMBIOS_DECODER);
>      if (path == NULL) {
> -        virSmbiosReportError(VIR_ERR_INTERNAL_ERROR,
> -                             _("Failed to find path for %s binary"),
> -                             SYSINFO_SMBIOS_DECODER);
> -        return NULL;
> +        return virCPUInfoSysinfoRead();
>      }
>  
>      cmd = virCommandNewArgList(path, "-q", "-t", "0,1,4,17", NULL);

  Hi Prerna,

that sounds like a good idea, and the patch seems to work but I have
doubt with the usefulness in its current form. Let me explain:

with dmidecode available on my system I get:

  ...
  <processor>
    <entry name='socket_destination'>Socket 775</entry>
    <entry name='type'>Central Processor</entry>
    <entry name='family'>Other</entry>
    <entry name='manufacturer'>Intel</entry>
    <entry name='signature'>Type 0, Family 6, Model 15, Stepping
11</entry>
    <entry name='version'>Intel(R) Core(TM)2 Duo CPU     E6550  @
2.33GHz</entry>
    <entry name='external_clock'>333 MHz</entry>
    <entry name='max_speed'>4000 MHz</entry>
    <entry name='status'>Populated, Enabled</entry>
  </processor>
  ...

without dmidecode and your patch plugged in I get

  <processor>
    <entry name='socket_destination'>0</entry>
    <entry name='type'>Intel(R) Core(TM)2 Duo CPU     E6550  @
2.33GHz</entry>
    <entry name='family'>6</entry>
    <entry name='manufacturer'>GenuineIntel</entry>
  </processor>
  <processor>
    <entry name='socket_destination'>1</entry>
    <entry name='type'>Intel(R) Core(TM)2 Duo CPU     E6550  @
2.33GHz</entry>
    <entry name='family'>6</entry>
    <entry name='manufacturer'>GenuineIntel</entry>
  </processor>

so basically we get informations, some are available in both case but
differently, and worse, in the fallback case we get 2 physical processor
entries (I have only one) which is of course different from the single
processor that we get with dmidecode.

  So 1/ is seems to me the fallback data can't be parsed
programmatically as a replacement of the original ones
     2/ the data may be misunderstood and lead to erroneous
decision for example a schedule may start to stack 2 time more
load on my machine based on the difference of report.

 So I'm a bit worried about applying it as-is, I'm afraid we need
to reconcile the output (as much as possible considering there
is less data) between both cases.

  That said I think patch 1/2 looks fine to me, and could probably be
applied as-is,

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/