similar to: concurrent writes to xenbus device

Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/drivers/char/mem.c =================================================================== --- head-2007-02-27.orig/drivers/char/mem.c 2007-03-05 10:00:18.000000000 +0100 +++ head-2007-02-27/drivers/char/mem.c 2007-02-27 16:27:37.000000000 +0100 @@ -787,7 +787,7 @@ static const struct file_operations mem_ .open =

So far only the watch path was checked to be zero terminated, while the watch token was merely assumed to be. Additionally, none of the three associated memory allocations got checked for being successful. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/drivers/xen/xenbus/xenbus_dev.c +++ b/drivers/xen/xenbus/xenbus_dev.c @@ -269,18 +269,24 @@ static ssize_t xenbus_dev_write(struct f

Hello, This patch allows userspace tools on a domU to setup a watch on the xenstore. It does this by intercepting XS_WATCH requests written to /proc/xen/xenbus and then re-submitting the request to the in-kernel xenstore interface, in linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_xs.c. When a callback occurs, an in-kernel function is invoked, which then reconstructs a response in the format

We''ve been noticing a lot of these errors when booting VMs since we moved to 3.0.3 - I''ve traced this to the hotplug scripts in Dom0 taking >10s to run to completion and specifically the vif-bridge script taking >=9s to plug the vif into the s/w bridge on occasion - was wondering if anyone has any insight into why it might take this long. I added some instrumentation to

Previously, I used to run 2.6.18 kernel built from Xen sources. I just tried to run a 2.6.25.1 domU kernel on top of Xen 3.2 - after changing domU''s config file here and there, I successfully booted the guest, but I''m still unable to use xm console. When I start the domain, it displays all kernel and bootup messages, but I don''t get any prompt after the bootup is

include/xen/xenbus.h nicely declares struct xenbus_driver''s ''ids'' member as pointer to const... As usual, written and tested on 2.6.25-rc3 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-02-26/drivers/xen/blkback/xenbus.c

I am running debian lenny, with the standard Xen 3.2 packages, with the 2.6.18-6-xen-686 kernel as dom0, and 2.6.24-1-xen-686 as domU. Everything is working fine apart from the console and the PCI passthrough. I am getting these errors in the domU on startup: XENBUS: Device with no driver: device/pci/0 XENBUS: Device with no driver: device/console/0 Does this mean the modules are missing?

flight 6714 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/6714/ Regressions :-( Tests which did not succeed and are blocking: build-amd64-oldkern 4 xen-build fail REGR. vs. 6658 build-amd64 4 xen-build fail REGR. vs. 6658 build-i386-oldkern 4 xen-build fail REGR. vs. 6658

One could even debate whether reserved bit faults are always fatal (and should never be propagated to the guest)... Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-01-28/xen/arch/x86/traps.c =================================================================== --- 2008-01-28.orig/xen/arch/x86/traps.c 2008-01-28 11:31:44.000000000 +0100 +++ 2008-01-28/xen/arch/x86/traps.c

Hi, This patch series fixes the S3 resume of a domain running xenstored and a frontend over xenbus (xen-netfront in my use case). As device resume is happening before process resume, the xenbus frontend resume is hanging if xenstored is not running, thus causing a deadlock. This patch series is fixing that issue by deferring the xenbus frontend resume when we are running xenstored in that same

.. is out of sync on i386 and x86-64 - should it be allowed on i386, or should it be suppressed on x86-64? Since Xen fails ill accesses, I would assume enabling it on i386 is fine. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

The xenbus bus type uses device_create_file to assign all used device attributes. However it does not remove them when the device goes away. This patch uses the dev_attrs field of the bus type to specify default attributes for all devices. Signed-off-by: Bastian Blank <waldi at debian.org> --- drivers/xen/xenbus/xenbus_probe.c | 41 +++++++++------------------

The xenbus bus type uses device_create_file to assign all used device attributes. However it does not remove them when the device goes away. This patch uses the dev_attrs field of the bus type to specify default attributes for all devices. Signed-off-by: Bastian Blank <waldi at debian.org> --- drivers/xen/xenbus/xenbus_probe.c | 41 +++++++++------------------

The xenbus bus type uses device_create_file to assign all used device attributes. However it does not remove them when the device goes away. This patch uses the dev_attrs field of the bus type to specify default attributes for all devices. Signed-off-by: Bastian Blank <waldi at debian.org> --- drivers/xen/xenbus/xenbus_probe.c | 41 +++++++++------------------

Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-09-19/xen/arch/x86/platform_hypercall.c =================================================================== --- 2008-09-19.orig/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:02.000000000 +0200 +++ 2008-09-19/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:56.000000000 +0200 @@ -21,7 +21,7 @@ #include <xen/acpi.h>

It seems that xenstore watches do not work from domU userspace (they obviously do for drivers). In some preliminary debugging of this, there are two aspects of the failure: not sending the watch to xenstore and not handling watch events for userspace watches. The former can be easily fixed by adding the missing ''case XS_WATCH:'' to xenbus_dev_write() in xenbus_dev.c. The

While shuffling quite a few things around, this gets us closer to native, which clearly had a reason to do the DMI scan early. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-08/arch/i386/mm/ioremap-xen.c =================================================================== --- head-2007-02-08.orig/arch/i386/mm/ioremap-xen.c 2007-02-08 17:07:13.000000000 +0100 +++

Hi! I catched two pieces with debug and crash_debug enabled. One of them fixes a build error even without the -Wcast-qual flag. Patch attached. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

clear_IO_APIC_pin() ignores entries that are set to delivery mode SMI. While this seems reasonable if the entry was unmasked, I consider it dubious for masked entries. In Linux, such behavior is benign since when the entry later is being used for some normal interrupt, the old setting is simply overwritten. In Xen, however, ioapic_guest_write() uses the vector field to determine the previous

Hi Konrad, I just tried linux-3.4-rc0 (linus his tree, last commit f52b69f86e27903d6896ed5fa7cd280fec8de532) with 3 additional branches from your tree pulled on top of that: branch stable/for-ingo-3.4.v2 (required for dom0 to boot) branch stable/for-jens-3.4 branch stable/for-jens-3.4-bugfixes Hypervisor is xen-4.1.3-rc1-pre linux 3.3 vanilla works fine Booting dom0 goes fine, but