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

[Daniel Veillard]

On Thu, Mar 15, 2012 at 04:17:20PM +0530, Prerna wrote:
> From: Prerna Saxena <prerna at linux.vnet.ibm.com>
> Date: Thu, 16 Feb 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 Blake:
> (http://www.redhat.com/archives/libvir-list/2012-February/msg00509.html)
> 
> Also updated to display only socket-level information under '<processor>'
> XML tags, to bring it analogous to 'dmidecode' output.
> (Observed by Daniel Veillard :
> http://www.spinics.net/linux/fedora/libvir/msg53922.html)

  Hum ...

I tried again, there is one good news:
  - the output without dmidecode shows the same number of processors
    than with it

The bad news:
  - the output still don't match here

I get the following without dmidecode:

<sysinfo type='smbios'>
  <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>
</sysinfo>

and the same fields when dmidecode is present:

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

That's clearly not a subset, socket destination shows the socket number
instead of the socket type, what is shown as 'type' without dmidecode
is 'version' with it, family values diverge. Seems we should be able
to improve this:

  - change the 'type' to go into 'version'
  - set 'status' to 'Populated, Enabled' as this is the case for any CPU
    shown in /proc/cpuinfo
  - if cpu family/model/stepping are shown in /proc/cpuinfo then
    try to build a subset of signature

in my case I have in /proc/cpuinfo

vendor_id   : GenuineIntel
cpu family  : 6
model       : 15
model name  : Intel(R) Core(TM)2 Duo CPU     E6550  @ 2.33GHz
stepping    : 11
microcode   : 0xba
cpu MHz     : 1998.000
cache size  : 4096 KB
physical id : 0

we should be able to generate from it

  <processor>
    <entry name='manufacturer'>GenuineIntel</entry>
    <entry name='signature'>Family 6, Model 15, Stepping 11</entry>
    <entry name='version'>Intel(R) Core(TM)2 Duo CPU     E6550  @
2.33GHz</entry>
    <entry name='status'>Populated, Enabled</entry>
  </processor>

those informations are the ones which are really useful from a
management perspective, i.e. knowing that there is a plugged CPU,
and which kind of CPU. More importantly the format would stay the
same, allowing proper processing by an application.

But currently with the current version of the patch a program
parsing "signature " and "version" to make guest scheduling informations
would be at best confused by the current output if dmidecode is not
present.

So I still suggest to refine the patch there, it's not urgent, I will
apply 1/2 since that's important for PPC but let's try to fix this
next week so we can carry both patches in 0.9.11 :-)
I would rather fix this next week so that if we need to change the PPC
output we should do it before the release.

  thanks !

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/