From mboxrd@z Thu Jan 1 00:00:00 1970 From: aq Subject: Re: [PATCH] xm --version Date: Tue, 7 Jun 2005 19:22:25 +0900 Message-ID: <9cde8bff0506070322977620@mail.gmail.com> References: Reply-To: aq Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: Xen Dev List-Id: xen-devel@lists.xenproject.org On 6/6/05, Ian Pratt wrote: > > > Where does 'machine' come from? Shouldn't it be x86_32? > > > > this is not what the patch does, but in the original code. > > actually "machine" is from "uname" syscall, run in dom0. > > libxc just gets the result from "uname", together with > > dom0_release, dom0_version. > > > > should we fix it to x86_32 or x86_64? >=20 > Ideally the architecture should come from Xen rather than the dom0 > kernel, but I guess this isn't a big deal right now since we don't > support running 32 bit paravirt guests on a 64 bit hypervisor, and even > if we did you probably wouldn't want to do it for dom0. >=20 > > > > > > Also, isn't there a tools version field we could print as well? > > > > > yes, that is fine, but where to get the xm version? lets put > > it somewhere into xm code? i am not sure where to put it. and > > actually what is the current version of xm? we better ask > > Mike to help this problem? >=20 > I guess its more interesting to know the xend or libxc version, but I > guess we can assume them to all come from the same package/rpm. We > probably need to add a version identifier to the tools. >=20 > > > > cores : 1 > > > > hyperthreads_per_core : 1 > > > > > > I'd like to add a bit more information here, to take of > > ccNUMA systems > > > with multicore and hyperthreadsing, e.g. for a system with > > 2 dual core > > > hyperthreaded Xeons: > > > > > > logical_cpus : 8 > > > > sorry for my ignorance (never play with 2 or more cpus system > > before, poor me!), how come 2 dual core hyperthreaded Xeons > > has "8 logical cpus"? you must meant "4 logical cpus" >=20 > 2 sockets * 2 cores * 2 hyperthreads =3D 8 logical CPUs. >=20 > Xen doesn't currently distinguish between sockets and cores, so for the > moment the interface should just return 'sockets_per_node =3D 4'. We can > fix Xen up later. >=20 Ian, i look at the xen source code, and looks like "noht" option is never used anywhere? also ht_per_core is always set to 1? does xen really support HyperThreading now ? (i doubt that) regards, aq