From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: [Xen-staging] [xen-unstable] Added some more fields to host_cpu. Date: Fri, 02 Mar 2007 15:01:39 -0600 Message-ID: <1172869299.24623.28.camel@basalt> References: <200702270156.l1R1uLfk014775@latara.uk.xensource.com> <1172867986.5941.49.camel@bling> Reply-To: Hollis Blanchard Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1172867986.5941.49.camel@bling> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Alex Williamson Cc: Jimi Xenidis , xen-devel , ewan@xensource.com List-Id: xen-devel@lists.xenproject.org On Fri, 2007-03-02 at 13:39 -0700, Alex Williamson wrote: > > On ia64, dom0 doesn't automatically get vcpus for each physical cpu, > so the first problem is that we're not going to have a /proc/cpuinfo > entry for every cpu in self.cpus.keys. I think it's likely x86 could > run into this problem too if a cpu was hotplugged or booted with the > dom0_max_vcpus options. Not sure if this affects us. > The second problem is that /proc/cpuinfo fields are very architecture > specific. I'd suggest importing arch and having separate cases for x86, > ia64, and powerpc. For ia64, think the most appropriate mapping would > be: > > self.cpus[u].update( > { 'host' : self.uuid, > 'features' : cpu_features, > 'speed' : int(float(cpuinfo[0]['cpu MHz'])), > 'vendor' : cpuinfo[0]['vendor'], > 'modelname': cpuinfo[0]['family'], > 'stepping' : cpuinfo[0]['model'], > 'flags' : cpuinfo[0]['features'], > }) This absolutely does. Ewan, what are you trying to do here, and could you please revert it until we figure out a solution that will work? -- Hollis Blanchard IBM Linux Technology Center