search for: libxl_cpumap

Hello, Third version of the NUMA placement series Xen 4.2. All the comments received during v2''s review have been addressed (more details in single changelogs). The most notable changes are the following: - the libxl_cpumap --> libxl_bitmap renaming has been rebased on top of the recent patches that allows us to allocate bitmaps of different sizes; - the heuristics for deciding which NUMA placement is the best one has been redesigned, so that it now provides total ordering. Here it is what this posting cont...

...; diff -r ac45608496cd -r cdb947baea10 tools/libxl/gentest.py --- a/tools/libxl/gentest.py Thu May 17 16:39:51 2012 +0100 +++ b/tools/libxl/gentest.py Thu May 17 17:51:32 2012 +0100 @@ -21,8 +21,7 @@ def randomize_enum(e): return random.choice([v.name for v in e.values]) handcoded = ["libxl_cpumap", "libxl_key_value_list", - "libxl_cpuid_policy_list", "libxl_file_reference", - "libxl_string_list"] + "libxl_cpuid_policy_list", "libxl_string_list"] def gen_rand_init(ty, v, indent = "...

...that: * rebased * corrected Makefile dependencies to include libxltypes.idl * manually implemented libxl_file_reference_destroy since it is more complex than just freeing the contained types. * Made libxl_file_reference_{map,unmap} into internal functions. * Added typedefs for various types: - libxl_cpumap - libxl_hwcap * Made libxl_xen_console_reader an opaque type and by making the definition internal. * moved more types from libxl.h to _libxl_types.h. I think all those which it makes sense to generate are now accounted for. * disabled destructor generation for types which have no interesting...

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

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

...uot;Buffer overflow"); + return -1; + } + + memcpy(ptr, tmp, sz); + return 0; +} + +static PyObject *fixed_bytearray_get(const uint8_t *ptr, size_t len) +{ + return PyByteArray_FromStringAndSize((const char *)ptr, len); +} + +#include "_pyxl_types.h" + +int attrib__libxl_cpumap_set(PyObject *v, libxl_cpumap *pptr) +{ + return -1; +} + +int attrib__libxl_domain_build_state_ptr_set(PyObject *v, libxl_domain_build_state **pptr) +{ + return -1; +} + +int attrib__libxl_file_reference_set(PyObject *v, libxl_file_reference *pptr) +{ + return -1; +} + +int attrib__libxl_...

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

Hey Jim, I was wondering if you or someone on your team could give me an idea what the status of libxl support is in libvirt, particularly wrt various releases? I''m asking because I''m going to UDS next week to talk about the 13.04 release, and it would be good to get Xen 4.2 in; but that in part depends on whether there will be libvirt support for 4.2 in whatever version of