From: Alex Williamson <alex.williamson@hp.com>
To: ewan@xensource.com
Cc: Jimi Xenidis <jimix@watson.ibm.com>,
xen-devel <xen-devel@lists.xensource.com>,
Hollis Blanchard <hollisb@us.ibm.com>
Subject: Re: [Xen-staging] [xen-unstable] Added some more fields to host_cpu.
Date: Fri, 02 Mar 2007 13:39:46 -0700 [thread overview]
Message-ID: <1172867986.5941.49.camel@bling> (raw)
In-Reply-To: <200702270156.l1R1uLfk014775@latara.uk.xensource.com>
Hi Ewan,
There are a couple problems with this patch for non-x86 (and maybe
even on x86), see below:
On Tue, 2007-02-27 at 01:56 +0000, Xen staging patchbot-unstable wrote:
> diff -r e7b2a282c9e7 -r 50e0616fd012 tools/python/xen/xend/XendNode.py
> --- a/tools/python/xen/xend/XendNode.py Mon Feb 26 17:20:36 2007 +0000
> +++ b/tools/python/xen/xend/XendNode.py Tue Feb 27 00:37:27 2007 +0000
> @@ -81,7 +81,7 @@ class XendNode:
> for cpu_uuid, cpu in saved_cpus.items():
> self.cpus[cpu_uuid] = cpu
>
> - # verify we have enough cpus here
> + cpuinfo = parse_proc_cpuinfo()
> physinfo = self.physinfo_dict()
> cpu_count = physinfo['nr_cpus']
> cpu_features = physinfo['hw_caps']
> @@ -91,12 +91,23 @@ class XendNode:
> if cpu_count != len(self.cpus):
> self.cpus = {}
> for i in range(cpu_count):
> - cpu_uuid = uuid.createString()
> - cpu_info = {'uuid': cpu_uuid,
> - 'host': self.uuid,
> - 'number': i,
> - 'features': cpu_features}
> - self.cpus[cpu_uuid] = cpu_info
> + u = uuid.createString()
> + self.cpus[u] = {'uuid': u, 'number': i }
> +
> + for u in self.cpus.keys():
> + log.error(self.cpus[u])
> + number = self.cpus[u]['number']
> + log.error(number)
> + log.error(cpuinfo)
> + self.cpus[u].update(
> + { 'host' : self.uuid,
> + 'features' : cpu_features,
> + 'speed' : int(float(cpuinfo[number]['cpu MHz'])),
> + 'vendor' : cpuinfo[number]['vendor_id'],
> + 'modelname': cpuinfo[number]['model name'],
> + 'stepping' : cpuinfo[number]['stepping'],
> + 'flags' : cpuinfo[number]['flags'],
> + })
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.
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'],
})
Hollis or Jimi might be able to chime in with identifiers that would
work on powerpc. Thanks,
Alex
--
Alex Williamson HP Open Source & Linux Org.
next parent reply other threads:[~2007-03-02 20:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200702270156.l1R1uLfk014775@latara.uk.xensource.com>
2007-03-02 20:39 ` Alex Williamson [this message]
2007-03-02 20:46 ` Re: [Xen-staging] [xen-unstable] Added some more fields to host_cpu Keir Fraser
2007-03-02 20:55 ` Alex Williamson
2007-03-02 20:58 ` Keir Fraser
2007-03-02 20:47 ` John Levon
2007-03-02 20:54 ` John Levon
2007-03-02 21:01 ` Hollis Blanchard
2007-03-07 17:54 ` Hollis Blanchard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1172867986.5941.49.camel@bling \
--to=alex.williamson@hp.com \
--cc=ewan@xensource.com \
--cc=hollisb@us.ibm.com \
--cc=jimix@watson.ibm.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.