similar to: [PATCH] remove another xc_dom0_op() user

Once Xen calculates nr_nodes properly, all nr_cpu calculations based on nr_nodes * sockets_per_node * cores_per_socket * threads_per_core are broken. The easy fix is to replace those calculations with a new field, nr_cpus in physinfo which is calculated by num_online_cpus(). This patch does so and attempts to change all users over to nr_cpus field in physinfo. This patch touches

This patch modifies the physinfo hcall to export NUMA CPU and Memory topology information. The new physinfo hcall is integrated into libxc and xend (xm info specifically). Included in this patch is a minor tweak to xm-test''s xm info testcase. The new fields in xm info are: nr_nodes : 4 mem_chunks : node0:0x0000000000000000-0x0000000190000000

Last year we had a discussion[1] about how the hypercall ABI unfortunately contains fields that change width between 32- and 64-bit builds. This is a huge problem as we come up on the python management stack for ppc64, since the distributions ship 32-bit python. A 32-bit python/libxc cannot currently manage a 64-bit hypervisor. I had a patch but was unable to test it, and some other things were

Signed-off-by: Vincent Hanquez <vincent.hanquez@eu.citrix.com> --- tools/ocaml/Makefile | 2 +- tools/ocaml/common.make | 2 +- tools/ocaml/libs/xl/xl.ml | 209 ++++++++++++ tools/ocaml/libs/xl/xl.mli | 209 ++++++++++++ tools/ocaml/libs/xl/xl_stubs.c | 706 ++++++++++++++++++++++++++++++++++++++++ 5 files changed, 1126 insertions(+), 2 deletions(-)

Please CC as I''m not subscribed to valgrind-developers. Under Xen the toolstack is responsible for managing the domains in the system, e.g. creating, destroying, and otherwise manipulating them. To do this it uses a number of ioctls on the /proc/xen/privcmd device. Most of these (the MMAPBATCH ones) simply set things up such that a subsequenct mmap call will map the desired guest

The following patchset adds NUMA support to the hypervisor. This includes: - A full SRAT table parser for 32-bit and 64-bit, based on the ACPI NUMA parser from linux 2.6.16.29 with data structures to represent NUMA cpu and memory topology, and NUMA emulation (fake=). - Changes to the Xen page allocator adding a per-node bucket for each zone. Xen will continue to prioritize using the

Any way to get access to the number of CPU's, optionally their type, from within R? In linux I can just read /proc/cpuinfo but for win/mac ? Thanks! H?vard -- H?vard Rue Department of Mathematical Sciences Norwegian University of Science and Technology N-7491 Trondheim, Norway Voice: +47-7359-3533 URL : http://www.math.ntnu.no/~hrue Fax : +47-7359-3524 Email: havard.rue

This patch makes "xm info" show information on xen version, compile info, number of socket/core, etc... In order to do that, it extends physinfo hypercall to return number of socket, adds few functions to libxc and extends python wrapper correspondingly. Here is the output of new "xm info": -- system : Linux host : ubuntu xen_release

While compiling XEN with XSM_ENABLE=y and FLASK_ENABLE=y, I received the following error. gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -Wno-unused-but-set-variable -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe

On 03/02/2015 01:39 PM, Wayne Mills wrote: > Thanks Cole, unfortunately I'm a n00b in this area so your response just > raised many more questions for me :/ > > * what are the config file names for libxl, libvirt and virt-manager > * where are they located in the respective source trees > * are the build flags defined in those config files? > * libxl is part of xen 4.5.0

The patchset will add basic NUMA support to Xen (hypervisor only). We borrowed from Linux support for NUMA SRAT table parsing, discontiguous memory tracking (mem chunks), and cpu support (node_to_cpumask etc). The hypervisor parses the SRAT tables and constructs mappings for each node such as node to cpu mappings and memory range to node mappings. Using this information, we also modified the

Specifically, what values are or aren''t accepted as CPU identifier, and how the values get interpreted should be consistent across sub-commands (intended behavior now: non-negative values are okay, and along with omitting the argument, specifying "all" will also be accepted). For error handling, error messages should get consistently issued to stderr, and the tool should now

Testing on an 8-node 128-way NUMA machine has exposed a problem with Xen''s nr_cpus calculation. In this case, since Xen cuts off recognized CPUs at 32, the machine appears to have 16 CPUs on the first and second nodes and none on the remaining nodes. Given this asymmetry, the calculation of sockets_per_node (which is later used to calculate nr_cpus) is incorrect:

I downloaded and untarred the deb package and grepped for 'configure', but none of the hits were configure commands. Is there a better way to find it? Wayne On Mon, Mar 2, 2015 at 3:08 PM, Cole Robinson <crobinso@redhat.com> wrote: > On 03/02/2015 01:39 PM, Wayne Mills wrote: > > Thanks Cole, unfortunately I'm a n00b in this area so your response just > >

On 03/02/2015 10:55 AM, Wayne Mills wrote: > Hi, > > I built and installed Xen 4.5.0 from source, on top of Ubuntu 14.04.2, using > "make world" and "make install" targets. I then installed latest virt-manager > from pre-built packages. After bringing up virt-manager I attempt to connect > to Xen hypervisor and got: > > unable to connect to

Thanks Cole, unfortunately I'm a n00b in this area so your response just raised many more questions for me :/ * what are the config file names for libxl, libvirt and virt-manager * where are they located in the respective source trees * are the build flags defined in those config files? * libxl is part of xen 4.5.0 distro (xen/tools/libxl after untarring). But no config file is in

Changes since v1: - Fix a double-free bug introduced by v1, pointed out by Stefano where internal pointer was being passed back to caller from libxl_create_stubdom() 8<---------------------------------------------------------------------- Currently scratch variables allocated by libxl have the same lifetime as the context. While this is suitable for one off invocations of xl. It is not