similar to: [PATCH 00 of 10 v3] Automatic NUMA placement for xl

Hi all, This is the second take of a patch that I submitted some time ago for allowing specifying vcpu pinning taking NUMA nodes into account. IOW, something like this: * "nodes:0-3": all pCPUs of nodes 0,1,2,3;  * "nodes:0-3,^node:2": all pCPUS of nodes 0,1,3;  * "1,nodes:1-2,^6": pCPU 1 plus all pCPUs of nodes 1,2    but not pCPU 6; v1 was a single patch, this is

a, libxl_event.h is included in libxl.h. So, the former one also need to be installed. b, define __XEN_TOOLS__ in libxl.h: the head file "xen/sysctl.h" need check this macro. It is the same way used by the xen libxc public headers(tools/libxc/xenctrl.h and tools/libxc/xenctrlosdep.h). Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com> diff -r 87218bd367be

The series introduces auto-generation of the type definitions used in the libxl interface followed by auto-generation of a destructor function for each type. In the future it may be possible to use the related data structures for other purposes, for example auto-generation of the functions to marshal between C and language binding data types. tools/_libxl_types.h should be identical both before

Matthew Daley (13): libxl: fix unsigned less-than-0 comparison in e820_sanitize libxl: check for xc_domain_setmaxmem failure in libxl__build_pre libxl: correct file open success check in libxl__device_pci_reset libxl: don''t leak p in libxl__wait_for_backend libxl: remove unsigned less-than-0 comparison libxl: actually abort if initializing a ctx''s lock fails libxl:

Following series cleans up a few niggles in the libxl destructor autogeneration. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1337273492 -3600 # Node ID cdb947baea102aa6a1d53472f8a3e5f2d6cc485e # Parent ac45608496cd85b0bf1aed6e5b869b4a86ca672f libxl: do not overwrite user supplied config when running bootloader. Currently when running the bootloader libxl will update b_info->u.pv.kernel, .ramdisk, .cmdline and .bootloader. This can

Hi, I''ve installed xen-unstable 4.2 from actual git (last commit was 4dc7dbef5400f0608321d579aebb57f933e8f707). When I start a domU with xm all is fine include the cpu_weight I configured in my domU config. When I start the domU with xl then all my domU have the default cpu_weight of 256 instead of the configured one. Was the name of cpu_weight being changed for xl command ? My domU

Hi, I''ve installed xen-unstable 4.2 from actual git (last commit was 4dc7dbef5400f0608321d579aebb57f933e8f707). When I start a domU with xm all is fine include the cpu_weight I configured in my domU config. When I start the domU with xl then all my domU have the default cpu_weight of 256 instead of the configured one. Was the name of cpu_weight being changed for xl command ? My domU

About rationale, usage and (some small bits of) API. Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> --- Changes from v7: * avoid referring to 4.2 release as "upcoming". * libxl placement disabling key explicitly mentioned. * Limit of max 16 NUMA nodes explicitly mentioned. Changes from v6: * text updated to

hi i want to install libvirt-1.1.2 in xen -4.2.1. i installed int he following manner: 1. downloaded source from libvirt/org (libvirt-1.1.2) 2. untarred & run ./configure --with-xen=yes --with-libxl=yes 3. then make and make install. i also enabled the (xend-unix-server yes) in xend config file. i run libvirtd -v and getting the followning error: root@boss[libexec]#libvirtd -v

hi i want to install libvirt-1.1.2 in xen -4.2.1. i installed int he following manner: 1. downloaded source from libvirt/org (libvirt-1.1.2) 2. untarred & run ./configure --with-xen=yes --with-libxl=yes 3. then make and make install. i also enabled the (xend-unix-server yes) in xend config file. i run libvirtd -v and getting the followning error: root@boss[libexec]#libvirtd -v

The following series implements libxl_domain_config_init as per the libxl API requirement that each type has an init function. The first function does this in an open coded manner and is proposed for Xen 4.2. The second function is RFC only since it moves the definition of this type into the IDL and makes the required infrastructure updates to enable this. I think this is more 4.3 material at

libxl__domain_build_info_setdefault may be called several times, so rtc_timeoffset can''t be setted in it. Move rtc_timeoffset setting logic to libxl__build_pre. Reported-by: Teck Choon Giam <giamteckchoon@gmail.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn> --- tools/libxl/libxl_create.c | 9 ---------

This patch adds a new option for xen config files for directly mapping hardware io memory into a vm. Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 013270d..428da21 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g.

hi, thanks for your response. i cleaned that above one and installed in this following steps: * sudo apt-get install gcc make pkg-config libxml2-dev libgnutils-dev libdevmapper-dev libcurl4-gnutls-dev python-dev libpciaccess-dev libxen-dev libnl-dev * ./configure = --prefix=/usr --localstatedir=/var --sysconfdir=/etc --with-xen=yes --with-libxl=yes * make * make install now i am getting the

Hello. I would like to access the LLVM IR Instruction from which an SDNode (from SelectionDAG) originates. For this I have modified: - llvm/lib/CodeGen/SelectionDAGISel.cpp, SelectionDAGISel::SelectBasicBlock(), namely I put SDB->clear() at the beginning of the method in order to avoid clearing NodeMap after creating the initial SelectionDAG from LLVM IR, since I want to access

Hello. Quentin, retrieving the LLVM IR instruction from which an SDNode originates is useful during the instruction selection phase. For example, I need to recover the LLVM IR variable which is used to fill an entire vector with the ISD::BUILD_VECTOR target-independent SDNode . From the recovered LLVM IR variable I can walk on the use-def-chains in order to get the most complete

The following series of patches fill in most of the gaps in the OCaml bindings to libxl, to make them useful for clients such as xapi/xenopsd (from XCP). There are a number of bugfixes to the existing bindings as well. I have an experimental version of xenopsd that successfully uses the new bindings. An earlier version of the first half of the series was submitted to the last by Ian Campbell on

On ven, 2013-09-27 at 12:56 +0530, cooldharma06 wrote: > root@boss[libexec]#libvirtd -v > 2013-09-27 07:24:46.501+0000: 29517: info : libvirt version: 1.1.2 > 2013-09-27 07:24:46.501+0000: 29517: error : libxlCapsInitHost:86 : > internal error: Failed to get node physical info from libxenlight > 2013-09-27 07:24:46.501+0000: 29517: error : > libxlStateInitialize:1362 : cannot

On ven, 2013-09-27 at 12:56 +0530, cooldharma06 wrote: > root@boss[libexec]#libvirtd -v > 2013-09-27 07:24:46.501+0000: 29517: info : libvirt version: 1.1.2 > 2013-09-27 07:24:46.501+0000: 29517: error : libxlCapsInitHost:86 : > internal error: Failed to get node physical info from libxenlight > 2013-09-27 07:24:46.501+0000: 29517: error : > libxlStateInitialize:1362 : cannot