search for: domain_build_info

...Xentoollog.create_stdio_logger ~level:Xentoollog.Debug () in + let ctx = Xenlight.ctx_alloc logger in + let c_info = { + Xenlight.Domain_create_info.hap = None; + Xenlight.Domain_create_info.oos = None; + Xenlight.Domain_create_info.name = "Test; + } + and b_info = { + Xenlight.Domain_build_info.max_vcpus = 1; + Xenlight.Domain_build_info.avail_vcpus = [| |]; + Xenlight.Domain_build_info.cpumap = [| |]; + Xenlight.Domain_build_info.numa_placement = None; + Xenlight.Domain_build_info.tsc_mode = Xenlight.TSC_MODE_DEFAULT; + Xenlight.Domain_build_info.max_memkb = 1024L; + Xe...

...for modifying the behaviour of +the placement algorithm. However, if your program is calling libxl, +it is possible to set the `numa_placement` build info key to `false` +(it is `true` by default) with something like the below, to prevent +any placement from happening: + + libxl_defbool_set(&domain_build_info->numa_placement, false); + +Also, if `numa_placement` is set to `true`, the domain must not +have any cpu affinity (i.e., `domain_build_info->cpumap` must +have all its bits set, as it is by default), or domain creation +will fail returning `ERROR_INVAL`. + +Besides than that, looking and/or...

...virtualisation of HVM Guests The following options allow Paravirtualised features (such as devices) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 8417661..d39ecbe 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -124,6 +124,17 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT) b_info->target_memkb = b_info->max_memkb; + libxl_defbool_setdefault(&b_info->localtime, false); + if (libxl_defbool_val(b_info->localtime)) { + time_t t; + struct tm *t...

...* `pci_power_mgmt=BOOLEAN`: XXX diff -r 460b507e15f8 -r bc79b560aafa tools/libxl/libxl_dom.c --- a/tools/libxl/libxl_dom.c Thu Nov 10 10:18:29 2011 +0000 +++ b/tools/libxl/libxl_dom.c Thu Nov 10 10:54:39 2011 +0000 @@ -73,12 +73,29 @@ int libxl__build_pre(libxl__gc *gc, uint libxl_domain_build_info *info, libxl__domain_build_state *state) { libxl_ctx *ctx = libxl__gc_owner(gc); + int tsc_mode; xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus); xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT); if (info->type == LIBXL_DO...

...]) +libxl_iomem_range = Struct("iomem_range", [ + ("start", uint64), + ("number", uint64), + ]) + libxl_vga_interface_info = Struct("vga_interface_info", [ ("kind", libxl_vga_interface_type), ]) @@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("ioports", Array(libxl_ioport_range, "num_ioports")), ("irqs", Array(uint32, "num_irqs")), + ("iomem", Array(libxl_iomem_range, "num_iomem")),...

...]) +libxl_iomem_range = Struct("iomem_range", [ + ("start", uint64), + ("number", uint64), + ]) + libxl_vga_interface_info = Struct("vga_interface_info", [ ("kind", libxl_vga_interface_type), ]) @@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("ioports", Array(libxl_ioport_range, "num_ioports")), ("irqs", Array(uint32, "num_irqs")), + ("iomem", Array(libxl_iomem_range, "num_iomem")),...

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

...* - * Is a NOP on non-PV domains or those with no bootloader configured. - * - * Users should call libxl_file_reference_unmap on the kernel and - * ramdisk to cleanup or rely on libxl_domain_{build,restore} to do - * it. - */ -int libxl_run_bootloader(libxl_ctx *ctx, - libxl_domain_build_info *info, - libxl_device_disk *disk, - uint32_t domid, - libxl_asyncop_how *ao_how); - - /* 0 means ERROR_ENOMEM, which we have logged */ - - int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid, const...

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

...pped is true then the actual file may already be unlinked."""), ("mapped", integer), ("data", void), - ("size", size_t)], autogenerate_destructor=False) + ("size", size_t)], autogenerate_destructor=False, internal=True) libxl_domain_build_info = Struct("domain_build_info",[ ("max_vcpus", integer), @@ -240,17 +240,11 @@ libxl_device_net2 = Struct("device_net2" ]) libxl_device_pci = Struct("device_pci", [ - (None, Union(None, [("value", unsigned_integer), -...

...t also be diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 9379694..7f8b65a 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -311,6 +311,20 @@ #define LIBXL_HAVE_BUILDINFO_USBDEVICE_LIST 1 /* + * LIBXL_HAVE_BUILDINFO_USBVERSION + * + * If this is defined, then the libxl_domain_build_info structure will + * contain hvm.usbversion, a integer type that contains a USB + * controller version to specify on the qemu upstream command-line. + * + * If it is set, callers may use hvm.usbversion to specify if the usb + * controller is usb1, usb2 or usb3. + * + * If this is not defined, the hvm...

I just built 4.3.0 in order to get > 2GB of RAM in domU with GPU passthrough without crashes. Unfortunately, the same crashes still happen. Massive frame buffer corruption on domU before it locks up solid. It seems the PCI memory stomp is still happening. I am using qemu-dm, as I did on Xen 4.2.x. So whatever fix for this went into 4.3.0 didn''t fix it for me. Passing less than 2GB

This patch set adds XSM security labels to useful debugging output locations, and fixes some assumptions that all interrupts behaved like GSI interrupts (which had useful non-dynamic IDs). It also cleans up the policy build process and adds an example of how to use the user field in the security context. Debug output: [PATCH 01/10] xsm: Add security labels to event-channel dump [PATCH 02/10] xsm:

...from within libxl itself. Callers outside libxl, who * do not #include libxl_internal.h, are fine. */ diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 6cb6de6..5edc9cc 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -349,6 +349,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ libxl_device_vfb = Struct("device_vfb", [ ("backend_domid", libxl_domid), + ("backend_domname",string), ("devid", libxl_devid), ("vnc", libxl_vnc_info), ("sdl&...

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

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

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

The following series flushes my documentation queue and replaces previous postings of those patches. The main difference is that the xl cfg file is now formatted using POD instead of markdown and presented as a manpage. I have setup a cron job to build docs/html and publish it at http://xenbits.xen.org/docs/unstable/ (it''s a bit bare right now). The motivation for some of these patches