similar to: [PATCH 3/4] (Refactored) Add error checking in blktapctrl

[PATCH 4/4] Add libvdisk, and vdisk_tool vdisk-support.patch provides libvdisk, and vdisk_tool, as described in [PATCH 0/4] Signed-off-by: Boris Ostrovsky <bostrovsky@virtualiron.com> Signed-off-by: Ben Guthro <bguthro@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Migrate the last TSC values for more accurate timekeeping during live migration Signed-off-by: Dave Winchell <dwinchell@virtualiron.com> Signed-off-by: Ben Guthro <bguthro@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

NOTE: An applicable subset of this patch was also submitted to upstream qemu. SUMMARY: This patch fixes several bugs in serial.c (1) A typo in serial_save() where qemu_get_8s is called (should be qemu_put_8s) (2) No support provided in serial_load() for version_id == 1 (should unmarshal a 1 byte s->divider and should provide a default value for s->fcr (3) Call serial_ioport_write() to

For about the past week (perhaps a bit longer) I have been unable to use an automated script to build xen-unstable on a 32 bit machine. The build continues to ask about the following build parameter: I2O_EXT_ADAPTEC_DMA64 Choosing the default (Y) allows the build to continue to completion. After a little research, it looks like this parameter was pulled out of linux-defconfig_xen_x86_32 in

This is the xen part of the kthread patch This part simply fixes a compiler warning we get when compiling for a uniprocessor guest kernel. Signed-off-by: Ben Guthro <bguthro@virtualiron.com> Signed-off-by: Robert Phillips <rphillips@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

This implements a suggestion by Keir to remove the xenbus "ignore state transitions on shutdown" code for kernels without a shutdown callback. Signed-off-by: David Lively <dlively@virtualiron.com> Signed-off-by: Ben Guthro <bguthro@virtualrion.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Change unsigned to unsigned long for spinlock flags. This avoids x86_64 assembly error in some distros (SLES10) Signed-off-by: Ben Guthro <bguthro@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Intercept guest reads of MSR_IA32_MCG_CAP and limit the number of memory banks reported to one. This prevents us from trying to read status of non-existent banks when migrated to a machine with fewer banks. Signed-off-by: Ben Guthro Signed-off-by: David Lively <dlively@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Package: xen-utils-3.4 Version: 3.4.3~rc6-1 Severity: important blktapctrl doesn't start. This means that none of the tap: disks work (eg tap:aio). It produces this in the log BLKTAPCTRL[6569]: blktapctrl.c:788: blktapctrl: v1.0.0 BLKTAPCTRL[6569]: blktapctrl.c:790: Found driver: [raw image (aio)] BLKTAPCTRL[6569]: blktapctrl.c:790: Found driver: [raw image (sync)]

After a hiatus, I have made another attempt at getting the XCI code-base up-and-running, but have run into some issues that I am hoping someone can help me with. 1. I am finding that a large hurdle in getting this building is chasing down build dependencies, of which there are many. Since the wiki recommends that this be built on a 32bit Debian lenny system - does anyone have a list of necessary

Hi! When I try to compile xen-unstable on Sarge, I get this error and I don''t know how to solve it: make[3]: Entering directory `/root/xen-unstable/tools/blktap/drivers'' gcc -O2 -fomit-frame-pointer -DNDEBUG -m32 -march=i686 -Wall -Wstrict-prototypes -D__XEN_TOOLS__ -fPIC -Wall -Werror -Wno-unused -g3 -fno-strict-aliasing -I ../../../tools/libxc -I ../../libaio/src -I..

Package: xen-utils-3.4 Version: 3.4.3~rc6-1 Severity: important blktapctrl isn't started by default. If blktapctrl isn't started then none of the tap: disks (eg tap:aio) work. This functionality has been removed in tools-misc-xend-startup.diff @@ -120,24 +86,14 @@ if not sys.argv[1:]: print 'usage: %s {start|stop|reload|restart}' % sys.argv[0] elif

Keir, I noticed that a Shadow patch went into the 3.1.1 staging tree today. Does this mean that we should expect a 4th release candidate before the 3.1.1 release tag is official? If so - how much testing time are you going to give that release candidate before deciding whether a release tag, or another RC round is appropriate? Ben Guthro _______________________________________________

Andrew, I think bug 709 is caused by blktapctrl not daemonizing itself correctly and holding open a file descriptor that the xm-test python code is reading from. I''m not really very familiar with blktapctrl. If you''d like to pick up the bug or outline how you''d like it fixed---for example by copying the daemonize implementation from xenconsoled---that would be

Hi, I am running XEN 4.1 on Debian 6 and I cannot find blktapctrl process running. xend is started. I installed XEN from 4.1 source following instructions here: http://wiki.xensource.com/xenwiki/XenParavirtOps http://wiki.xensource.com/xenwiki/Xen4.0 Should there be a blktapctrl process running in this version? The problem I have encountered is that I can create a domain on a raw disk image but

I''m getting this message (subject line) in daemon.log every time I start or restart xend. I''m not sure if this is related to the fact that I cannot boot up my Windows domU from a VHD file. The Windows domU was working fine with Xen 4.0.0 (with 2.6.32.14 dom0 kernel). When I upgraded to Xen 4.0.1-rc4 (with 2.6.32.16 dom0 kernel), I can no long boot the Windows domU from VHD. The

Hi All I am using xen 3.3.0 version and I want to start network virtual interface on Dom U by using the following command # xend start *************************************************************** *************************************************************** ** WARNING: Currently emulating unsupported memory accesses ** ** in /lib/tls glibc libraries. The emulation is

The existing xc_domain_dumpcore is very specific to disk/file based output. Refactor the code slightly to allow more user-specified control. This is done by adding a parallel xc_domain_dumpcore2 (naming isn''t always my strong suit), which allows the specification of a callback routine and an opaque argument block. The existing dumpcore routine is modified to use the callback for all

Hello, I installed Xen 3.2.1 on Debian Lenny from packages. Then created image files with 'xen-create-image --size=2Gb --swap=128Mb --dhcp --dir=/xen --hostname=test'. Now I'm trying to run Debian in PV mode using the following configuration file: kernel = "/boot/vmlinuz-2.6.26-1-xen-686" ramdisk = "/boot/initrd.img-2.6.26-1-xen-686" memory = 128 name =

Before I get to entrenched in the ACPI code - I thought I''d ping the community to make sure nobody else has investigated this already - Can we present cores vs sockets for guest VCPUs? Right now, the number of total processors can be specified, but can we specify cores per socket? I see this potentially being an hvmloader function, as part of its acpi build code. Could this be