From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] Supporting reading of system information from BIOS. Date: Tue, 14 Oct 2014 11:48:39 +0100 Message-ID: <543CFF86.1060908@citrix.com> References: <20141014044407.GA1448@chroot-build.noidalab.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141014044407.GA1448@chroot-build.noidalab.local> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Rita Sinha , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 14/10/14 05:44, Rita Sinha wrote: Thanks for having a stab at this. Some comments inline > This patch is in response to http://wiki.xenproject.org/wiki/Outreach_Program_Projects#CPU.2FRAM.2FPCI_diagram_tool project for applying to OPW-Round9.It adds support for reading system architecture information from BIOS rather than from sysfs and proc interfaces since in a virtualisation enviroment, some of this information is no longer accurate, particularly any information based around numbers of cpus. Would you mind formatting this to 80 columns wide? Generally speaking, submission of patches need a Signed-off-by: tag. > --- > dmidecode.pl | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 51 insertions(+) > create mode 100644 dmidecode.pl > > diff --git a/dmidecode.pl b/dmidecode.pl > new file mode 100644 > index 0000000..76fdf78 > --- /dev/null > +++ b/dmidecode.pl > @@ -0,0 +1,51 @@ > +#!/usr/bin/perl > + > +# dmidecode.pl - a script to read the system architecture information > +# directly from the BIOS. Only for Linux. > +# > +# Rita Sinha (rita.sinha89@gmail.com) > +# OPW Program-Round9 > +# 14/10/14 > + > +`id -u` == 0 || die "must be run as root"; > + > +open(DmiFh, "/usr/sbin/dmidecode |") or > + die "problem running dmidecode"; > +$DmiNumProcs = 0; > +$DmiNumSockets = 0; > +while() > + { > + next unless /Central Processor/; > + # We've found a processor (or at least a socket), keep going > + while() > + { > + # Keep walking the dmidecode output to find out if > + # the socket has a processor in it. > + last if /^Handle/; > + next unless /Status/; > + $DmiNumSockets += 1; > + /Populated/ and $DmiNumProcs += 1; > + last; > + } > + } > +close DmiFh; > + > +open(CpuInfoFh, "/proc/cpuinfo") || die "failed to open /proc/cpuinfo!"; > +$CpuInfoNumProcs = 0; > +while() > + { > + next unless /^processor.*:/; > + ($CpuInfoNumProcs) += (/^processor.*: (\d+)/); > + } > +close CpuInfoFh; > + > +if ( $DmiNumProcs != $CpuInfoNumProcs ) > + { > + print "Warning: dmidecode reports $DmiNumProcs processors, kernel reports $CpuInfoNumProcs processors.\n"; > + } > + > +if ( $DmiNumProcs != $DmiNumSockets ) > + { > + print "Info: dmidecode reports $DmiNumSockets cpu sockets, but only $DmiNumProcs processors.\n"; > + } > + Running this script in dom0 yields: [root@fusebot ~]# ./dmidecode.pl Warning: dmidecode reports 1 processors, kernel reports 4 processors. This is a Xeon E3-1240 v3 system where dom0 has 4 vcpus. Under Xen, each vcpu appears as a separate processor, which is why /proc/cpuinfo and dmidecode disagree about the processor count. This also goes to show that /proc/cpuinfo only sees the virtual layout, not the physical layout. I think it might be worth starting with a design of the first task we discussed, including the indented source of the information to be used. ~Andrew