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)
Xen-devel mailing list