search for: flexarray

Displaying 11 results from an estimated 11 matches for "flexarray".

Did you mean: flex_array
2010 Aug 17
3
libxl build failure in latest xen
...-fPIC -I../../tools/libxc -I../../tools/include > -I../../tools/libxc -I../../tools/include -I../../tools/xenstore -I../../tools/include > -I../../tools/blktap2/control -I../../tools/blktap2/include -I../../tools/include > -Wl,-soname -Wl,libxenlight.so.1.0 -shared -o libxenlight.so.1.0.0 flexarray.o > libxl.o libxl_pci.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o > libxl_internal.o xenguest.o libxl_utils.o osdeps.o libxl_paths.o > libxl_bootloader.o libxl_blktap2.o > /usr/bin/ld: libxl_dom.o: relocation R_X86_64_PC32 against > `hvm_build_set_params'' can no...
2013 Apr 25
17
[PATCH V3] libxl: write IO ABI for disk frontends
...pe = libxl__domain_type(gc, domid); + if (type == LIBXL_DOMAIN_TYPE_INVALID) { + rc = ERROR_FAIL; + goto out; + } for (;;) { rc = libxl__xs_transaction_start(gc, &t); @@ -2156,6 +2166,24 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, flexarray_append(front, "device-type"); flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); + /* + * Old PV kernel disk frontends before 2.6.26 rely on tool stack to + * write disk native protocol to frontend node. Xend does this, por...
2012 Apr 13
1
[PATCH] libxl/build: print a pretty message if flex/bison are needed but not found
...ndif +ifeq ($(FLEX),) +%.c %.h:: %.l + $(error Flex is needed to compile libxl, please install it and rerun \ + configure) +endif + +ifeq ($(BISON),) +%.c %.h:: %.y + $(error Bison is needed to compile libxl, please install it an rerun \ + configure) +endif + LIBXL_LIBS += -lyajl LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ @@ -83,11 +95,11 @@ all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \ $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS) -%.c %.h: %.y +%.c %.h:: %.y @rm -f $*.[ch] $(BISON) --output=$*.c $< -%.c %.h: %.l +%.c %...
2011 Oct 11
5
[PATCH] libxl: reimplement buffer for bootloading and drop data if buffer is full
...:26:32 2011 +0200 +++ b/tools/libxl/libxl_bootloader.c Tue Oct 11 14:26:31 2011 +0200 @@ -21,6 +21,7 @@ #include <sys/stat.h> #include <sys/types.h> +#include <sys/ioctl.h> #include "libxl.h" #include "libxl_internal.h" @@ -28,7 +29,8 @@ #include "flexarray.h" #define XENCONSOLED_BUF_SIZE 16 -#define BOOTLOADER_BUF_SIZE 1024 +#define BOOTLOADER_BUF_SIZE 4096 +#define BOOTLOADER_TIMEOUT 1 static char **make_bootloader_args(libxl__gc *gc, libxl_domain_build_info *info, @@ -165,10 +167,11 @@ static pid_t for...
2011 Mar 21
9
Build problem: note: ''xtl_createlogger_stdiostream'' is defined in DSO .. so try adding it to the linker command line... libxenctrl.so.4.0: could not read symbols: Invalid operation
This is a Fedora Core 13 environment and I just noticed this as I update the xen-unstable tree: make -C libxl install make[3]: Entering directory `/home/konrad/ssd/xtt/xen-unstable/tools/libxl'' rm -f _libxl_paths.h.tmp.tmp; echo "SBINDIR=\"/usr/sbin\"" >> _libxl_paths.h.tmp.tmp; echo "BINDIR=\"/usr/bin\"" >> _libxl_paths.h.tmp.tmp;
2011 Dec 14
18
[PATCH 0 of 3] Support for VM generation ID save/restore and migrate
This patch series adds support for preservation of the VM generation ID buffer address in xenstore across save/restore and migrate, and also code to increment the value in all cases except for migration. The first patch modifies creation of the hvmloader key in xenstore and adds creation of a new read/write hvmloader/generation-id-addr key. The second patch changes hvmloader to use the new key (as
2013 Apr 18
9
[PATCH v5 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest
...ml/libs/xl/genwrap.py | 1 + 8 files changed, 677 insertions(+), 2 deletions(-) create mode 100644 tools/libxl/libxl_usb.c diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 2984051..866960a 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -74,7 +74,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_internal.o libxl_utils.o libxl_uuid.o \ libxl_json.o libxl_aoutils.o libxl_numa.o \ libxl_save_callout.o _libxl_save_msgs_callout.o \ - libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y) + libxl_qmp.o libxl_event.o libxl_fo...
2012 Jul 04
53
[PATCH 00 of 10 v3] Automatic NUMA placement for xl
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
2010 Aug 18
16
[PATCH 00 of 16] libxl: autogenerate type definitions and destructor functions
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
2009 Nov 18
6
[PATCH 1/3] libxenlight: Clean up logging arrangements
...vice_pci_add_xenstore(struct libxl_ctx *ctx, uint32_t domid, if (!back) return ERROR_NOMEM; - XL_LOG(ctx, XL_LOG_DEBUG, "Adding new pci device to xenstore\n"); + XL_LOG(ctx, XL_LOG_DEBUG, "Adding new pci device to xenstore"); num = atoi(num_devs); flexarray_set(back, boffset++, libxl_sprintf(ctx, "key-%d", num)); flexarray_set(back, boffset++, libxl_sprintf(ctx, PCI_BDF, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func)); @@ -1140,7 +1151,7 @@ static int libxl_device_pci_remove_xenstore(struct libxl_ctx *ctx, uint32_t...
2011 Jul 21
51
Linux Stubdom Problem
2011/7/19 Stefano Stabellini <stefano.stabellini@eu.citrix.com>: > CC''ing Tim and xen-devel > > On Mon, 18 Jul 2011, Jiageng Yu wrote: >> 2011/7/16 Stefano Stabellini <stefano.stabellini@eu.citrix.com>: >> > On Fri, 15 Jul 2011, Jiageng Yu wrote: >> >> 2011/7/15 Jiageng Yu <yujiageng734@gmail.com>: >> >> > 2011/7/15