This patch adds to xm a long-missing function: showing xen version and few extra information (thanks go to Keir and Mark for some suggestions). Here is the ouput of "xm info" after applying the patch (against -unstable ChangeSet@1.1677): --- #xm info system : Linux host : ubuntu xen_release : 3.0-devel xen_compile_by : root@localdomain xen_compiler : gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2) xen_compile_date : Mon Jun 6 00:30:22 EST 2005 dom0_release : 2.6.11.10-xen0 dom0_version : #3 Mon Jun 6 00:32:05 EST 2005 machine : i686 cores : 1 hyperthreads_per_core : 1 cpu_mhz : 1094 memory : 511 free_memory : 122 ---- You get the point. And here is what the patch does: - extend xen_version hypercall. the new hypercall keeps the old behavior if executing it with 0 as its parameter. But if give it the address of version_op_t structure (see version.h in the patch), it returns extra stuffs like xen_extraversion, compile date, compiler, etc... - libxc now has a new function to get xen version (and stuffs): xc_xen_version() - extend python wrapper for xc_xen_version() and use it in XendNode.py to get xen version and stuffs. Any comment? Signed-off-by: Nguyen Anh Quynh <aquynh@gmail.com> # diffstat xminfo2.patch tools/libxc/xc.h | 11 +++++++++++ tools/libxc/xc_misc.c | 18 ++++++++++++++++++ tools/python/xen/lowlevel/xc/xc.c | 29 +++++++++++++++++++++++++++++ tools/python/xen/xend/XendNode.py | 12 ++++++++---- xen/common/kernel.c | 22 ++++++++++++++++++---- xen/include/public/version.h | 22 ++++++++++++++++++++++ 6 files changed, 106 insertions(+), 8 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> This patch adds to xm a long-missing function: showing xen > version and few extra information (thanks go to Keir and Mark > for some suggestions). Here is the ouput of "xm info" after > applying the patch (against -unstable ChangeSet@1.1677):Thanks, but I''d like to make another couple of suggestions:> --- > #xm info > system : Linux > host : ubuntu > xen_release : 3.0-devel > xen_compile_by : root@localdomain > xen_compiler : gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2) > xen_compile_date : Mon Jun 6 00:30:22 EST 2005 > dom0_release : 2.6.11.10-xen0 > dom0_version : #3 Mon Jun 6 00:32:05 EST 2005 > machine : i686Where does ''machine'' come from? Shouldn''t it be x86_32? Also, isn''t there a tools version field we could print as well?> cores : 1 > hyperthreads_per_core : 1I''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 hyperthreads_per_core : 2 cores_per_socket : 2 sockets_per_node : 2 nodes : 1 This information should reflect the running system, rather than the capabilities of the hardware. i.e. if someone has booted with ''noht'' then hyperthreads_per_core should be 1 regardless of the hardware. This will clean up some other code in Xen that uses the flag. Thanks, Ian> cpu_mhz : 1094 > memory : 511 > free_memory : 122_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/6/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > This patch adds to xm a long-missing function: showing xen > > version and few extra information (thanks go to Keir and Mark > > for some suggestions). Here is the ouput of "xm info" after > > applying the patch (against -unstable ChangeSet@1.1677): > > Thanks, but I''d like to make another couple of suggestions: > > > --- > > #xm info > > system : Linux > > host : ubuntu > > xen_release : 3.0-devel > > xen_compile_by : root@localdomain > > xen_compiler : gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2) > > xen_compile_date : Mon Jun 6 00:30:22 EST 2005 > > dom0_release : 2.6.11.10-xen0 > > dom0_version : #3 Mon Jun 6 00:32:05 EST 2005 > > machine : i686 > > 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?> > 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?> > 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 : 8sorry 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"> hyperthreads_per_core : 2 > cores_per_socket : 2 > sockets_per_node : 2 > nodes : 1 > > This information should reflect the running system, rather than the > capabilities of the hardware. i.e. if someone has booted with ''noht'' > then hyperthreads_per_core should be 1 regardless of the hardware. This > will clean up some other code in Xen that uses the flag.i see, but how about applying this patch now, and solve what you propose above later? i will investigate this problem. regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6 Jun 2005, at 08:47, aq wrote:> 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" > >> hyperthreads_per_core : 2 >> cores_per_socket : 2 >> sockets_per_node : 2 >> nodes : 1The example looks forward to physical packages containing two cores, each of which has two threads. So, in a dual socket system, you''d have 2x2x2=8 logical cpus. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > 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@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/6/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> 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@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 supports hyperthreading just fine, and even does initial domain placement using an algorithm that understands it. In fact, it looks like we effectively lost the option to ever disable hyperthreading when the setup code got upgraded. It would be nice if part of your patch removed any reference to ''noht'', including in the documentation. Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/7/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > 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 supports hyperthreading just fine, and even does initial domain > placement using an algorithm that understands it. > > In fact, it looks like we effectively lost the option to ever disable > hyperthreading when the setup code got upgraded.can you confirm that ht_per_core is also wrongly set? it is set (=1) at arch/x86/setup.c or arch/ia64/smpboot.c, but never changed. but this variable is used somewhere, and got reported in "xm info", for example. so all of its usage are also wrong when we use HT? (because in that case ht_per_core must be 2)>It would be nice if > part of your patch removed any reference to ''noht'', including in the > documentation.fine, i will submit a patch on this problem. regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> can you confirm that ht_per_core is also wrongly set? it is > set (=1) at arch/x86/setup.c or arch/ia64/smpboot.c, but > never changed. but this variable is used somewhere, and got > reported in "xm info", for example. > > so all of its usage are also wrong when we use HT? (because > in that case ht_per_core must be 2)OK, that''s bad -- the code that initialised ht_per_core has also gone. What we need to do is to take the new code from Linux 2.6.12-rc5 that understands multicore, and correctly initialise ht_per_core and core_per_socket. We can hardwire socket_per_node=1 for the moment. Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/9/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > can you confirm that ht_per_core is also wrongly set? it is > > set (=1) at arch/x86/setup.c or arch/ia64/smpboot.c, but > > never changed. but this variable is used somewhere, and got > > reported in "xm info", for example. > > > > so all of its usage are also wrong when we use HT? (because > > in that case ht_per_core must be 2) > > OK, that''s bad -- the code that initialised ht_per_core has also gone. > > What we need to do is to take the new code from Linux 2.6.12-rc5 that > understands multicore, and correctly initialise ht_per_core and > core_per_socket. We can hardwire socket_per_node=1 for the moment. >anybody is working on this? if no, i will take it. regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel