On Thu, Mar 15, 2012 at 04:17:20PM +0530, Prerna wrote: > From: Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list