[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xm --version


  • To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
  • From: aq <aquynh@xxxxxxxxx>
  • Date: Tue, 7 Jun 2005 19:22:25 +0900
  • Cc: Xen Dev <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 07 Jun 2005 10:21:36 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i621LrMRsHFpPovB4VD/9tR9VuusyZCKDxApzTL2L5dQmcXOtI9n4f+2KiU8cpObhTRHzWQcCbb7OqUxfIkpGd2RShK2w5evURGPIXuo9LkQbnhj7xJrHSlmPcoBtnp+TVdSclHycXMeX974iyITcos0+nYrZqT5ZIH0OEmFEHw=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 6/6/05, Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx> 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?
> 
> 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.
> 
> > >
> > > 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?
> 
> 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.
> 
> > > > 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"
> 
> 2 sockets * 2 cores * 2 hyperthreads = 8 logical CPUs.
> 
> Xen doesn't currently distinguish between sockets and cores, so for the
> moment the interface should just return 'sockets_per_node = 4'. We can
> fix Xen up later.
> 

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.