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

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> > 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

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