On Tue, Mar 13, 2012 at 11:10:16AM +0530, Prerna Saxena wrote: > From: Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxx> > Signed-off-by: Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx> > --- > 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@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