[PATCH 00/11] [v2] misc changes for kexec in pv-on-hvm guests

[PATCH 00/11] [v2] misc changes for kexec in pv-on-hvm guests

[Olaf Hering]

The following series implement kexec in a pv-on-hvm guest.
I send it here once more for further review before bothering lkml.

With this series doing kexec in a loop is now possible.


A fixed kexec-tools-2.0.2 package is required:
http://lists.infradead.org/pipermail/kexec/2011-May/005026.html
However, as I just found out, xenfs unconditionally adds /proc/xen/capabilities
even for hvm guest.

So: how is a hvm guest supposed to be detected in 3.0?

Olaf

[PATCH 01/11] kexec: add kexec_is_loaded function

[Olaf Hering]

[-- Attachment #1: kexec_is_loaded.patch --]
[-- Type: text/plain, Size: 3106 bytes --]

Add a new function kexec_is_loaded to be used by subsequent changes for
kexec in Xen HVM guests with PV drivers loaded.

A kexec reboot in a HVM guest needs to unregister all resources such as
xenstore watches and virqs, otherwise the kexec kernel can not bind to
these resources again. But the unregister only needs to happen during a
kexec boot because the guest remains the same from the Xen point of
view. A normal reboot will shutdown and destroy the entire guest with
all its resources, then the guest will start again with a different
domain_id number. So doing all the unregister work would only delay
normal reboots.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 include/linux/kexec.h |    3 ++-
 kernel/kexec.c        |    8 +++++++-
 kernel/ksysfs.c       |    2 +-
 3 files changed, 10 insertions(+), 3 deletions(-)

Index: linux-3.0/include/linux/kexec.h
===================================================================
--- linux-3.0.orig/include/linux/kexec.h
+++ linux-3.0/include/linux/kexec.h
@@ -126,6 +126,7 @@ extern asmlinkage long compat_sys_kexec_
 extern struct page *kimage_alloc_control_pages(struct kimage *image,
 						unsigned int order);
 extern void crash_kexec(struct pt_regs *);
+extern int kexec_is_loaded(void);
 int kexec_should_crash(struct task_struct *);
 void crash_save_cpu(struct pt_regs *regs, int cpu);
 void crash_save_vmcoreinfo(void);
@@ -156,7 +157,6 @@ unsigned long paddr_vmcoreinfo_note(void
 #define VMCOREINFO_CONFIG(name) \
 	vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
 
-extern struct kimage *kexec_image;
 extern struct kimage *kexec_crash_image;
 
 #ifndef kexec_flush_icache_page
@@ -214,6 +214,7 @@ void crash_free_reserved_phys_range(unsi
 struct pt_regs;
 struct task_struct;
 static inline void crash_kexec(struct pt_regs *regs) { }
+static inline int kexec_is_loaded(void) { return 0; }
 static inline int kexec_should_crash(struct task_struct *p) { return 0; }
 #endif /* CONFIG_KEXEC */
 #endif /* LINUX_KEXEC_H */
Index: linux-3.0/kernel/kexec.c
===================================================================
--- linux-3.0.orig/kernel/kexec.c
+++ linux-3.0/kernel/kexec.c
@@ -934,7 +934,7 @@ static int kimage_load_segment(struct ki
  * kexec does not sync, or unmount filesystems so if you need
  * that to happen you need to do that yourself.
  */
-struct kimage *kexec_image;
+static struct kimage *kexec_image;
 struct kimage *kexec_crash_image;
 
 static DEFINE_MUTEX(kexec_mutex);
@@ -1567,3 +1567,9 @@ int kernel_kexec(void)
 	mutex_unlock(&kexec_mutex);
 	return error;
 }
+
+int kexec_is_loaded(void)
+{
+	return !!kexec_image;
+}
+EXPORT_SYMBOL_GPL(kexec_is_loaded);
Index: linux-3.0/kernel/ksysfs.c
===================================================================
--- linux-3.0.orig/kernel/ksysfs.c
+++ linux-3.0/kernel/ksysfs.c
@@ -90,7 +90,7 @@ KERNEL_ATTR_RW(profiling);
 static ssize_t kexec_loaded_show(struct kobject *kobj,
 				 struct kobj_attribute *attr, char *buf)
 {
-	return sprintf(buf, "%d\n", !!kexec_image);
+	return sprintf(buf, "%d\n", kexec_is_loaded());
 }
 KERNEL_ATTR_RO(kexec_loaded);

[PATCH 02/11] xen: remove BUG_ON from xen_teardown_timer

[Olaf Hering]

[-- Attachment #1: xen.xen_teardown_timer.remove_bugon.patch --]
[-- Type: text/plain, Size: 639 bytes --]

cpu #0 has no "online" entry in /sys/devices/system/cpu/cpu0/, so
setting this cpu to offline can not happen by accident.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 arch/x86/xen/time.c |    1 -
 1 file changed, 1 deletion(-)

Index: linux-3.0/arch/x86/xen/time.c
===================================================================
--- linux-3.0.orig/arch/x86/xen/time.c
+++ linux-3.0/arch/x86/xen/time.c
@@ -408,7 +408,6 @@ void xen_setup_timer(int cpu)
 void xen_teardown_timer(int cpu)
 {
 	struct clock_event_device *evt;
-	BUG_ON(cpu == 0);
 	evt = &per_cpu(xen_clock_events, cpu);
 	unbind_from_irqhandler(evt->irq, NULL);
 }

[PATCH 03/11] xen: use static initializers in xen-balloon.c

[Olaf Hering]

[-- Attachment #1: xen.balloon.static_initializer.patch --]
[-- Type: text/plain, Size: 1756 bytes --]

There is no need to use dynamic initializaion, it just confuses the reader.
Switch to static initializers like its used in other files.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 drivers/xen/xen-balloon.c |   18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

Index: linux-3.0/drivers/xen/xen-balloon.c
===================================================================
--- linux-3.0.orig/drivers/xen/xen-balloon.c
+++ linux-3.0/drivers/xen/xen-balloon.c
@@ -50,11 +50,6 @@ static struct sys_device balloon_sysdev;
 
 static int register_balloon(struct sys_device *sysdev);
 
-static struct xenbus_watch target_watch =
-{
-	.node = "memory/target"
-};
-
 /* React to a change in the target key */
 static void watch_target(struct xenbus_watch *watch,
 			 const char **vec, unsigned int len)
@@ -74,6 +69,11 @@ static void watch_target(struct xenbus_w
 	balloon_set_new_target(new_target >> (PAGE_SHIFT - 10));
 }
 
+static struct xenbus_watch target_watch = {
+	.node = "memory/target",
+	.callback = watch_target,
+};
+
 static int balloon_init_watcher(struct notifier_block *notifier,
 				unsigned long event,
 				void *data)
@@ -87,7 +87,9 @@ static int balloon_init_watcher(struct n
 	return NOTIFY_DONE;
 }
 
-static struct notifier_block xenstore_notifier;
+static struct notifier_block xenstore_notifier = {
+	.notifier_call = balloon_init_watcher,
+};
 
 static int __init balloon_init(void)
 {
@@ -97,10 +99,6 @@ static int __init balloon_init(void)
 	pr_info("xen-balloon: Initialising balloon driver.\n");
 
 	register_balloon(&balloon_sysdev);
-
-	target_watch.callback = watch_target;
-	xenstore_notifier.notifier_call = balloon_init_watcher;
-
 	register_xenstore_notifier(&xenstore_notifier);
 
 	return 0;

[PATCH 04/11] xen/hvm kexec: unregister timer interrupt during reboot

[Olaf Hering]

[-- Attachment #1: xen.syscore_ops.unbind.timer-irq.patch --]
[-- Type: text/plain, Size: 1921 bytes --]

Unregister the timer interrupt during kexec, otherwise the kexec kernel will
run into the BUG() in bind_virq_to_irq() when trying to bind to the
still registered virq.

v2:
 use kexec_is_loaded() function

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 arch/x86/xen/time.c |   30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

Index: linux-3.0/arch/x86/xen/time.c
===================================================================
--- linux-3.0.orig/arch/x86/xen/time.c
+++ linux-3.0/arch/x86/xen/time.c
@@ -14,6 +14,8 @@
 #include <linux/kernel_stat.h>
 #include <linux/math64.h>
 #include <linux/gfp.h>
+#include <linux/kexec.h>
+#include <linux/syscore_ops.h>
 
 #include <asm/pvclock.h>
 #include <asm/xen/hypervisor.h>
@@ -405,11 +407,19 @@ void xen_setup_timer(int cpu)
 	evt->irq = irq;
 }
 
-void xen_teardown_timer(int cpu)
+static void xen_unbind_timer(int cpu)
 {
 	struct clock_event_device *evt;
 	evt = &per_cpu(xen_clock_events, cpu);
-	unbind_from_irqhandler(evt->irq, NULL);
+	if (evt->irq >= 0) {
+		unbind_from_irqhandler(evt->irq, NULL);
+		evt->irq = -1;
+	}
+}
+
+void xen_teardown_timer(int cpu)
+{
+	xen_unbind_timer(cpu);
 }
 
 void xen_setup_cpu_clockevents(void)
@@ -477,6 +487,21 @@ void __init xen_init_time_ops(void)
 }
 
 #ifdef CONFIG_XEN_PVHVM
+static void xen_hvm_timer_shutdown(void)
+{
+	int cpu;
+
+	if (!kexec_is_loaded())
+		return;
+
+	for_each_online_cpu(cpu)
+		xen_unbind_timer(cpu);
+}
+
+static struct syscore_ops xen_hvmtimer_syscore_ops = {
+	.shutdown = xen_hvm_timer_shutdown,
+};
+
 static void xen_hvm_setup_cpu_clockevents(void)
 {
 	int cpu = smp_processor_id();
@@ -505,5 +530,6 @@ void __init xen_hvm_init_time_ops(void)
 	x86_platform.calibrate_tsc = xen_tsc_khz;
 	x86_platform.get_wallclock = xen_get_wallclock;
 	x86_platform.set_wallclock = xen_set_wallclock;
+	register_syscore_ops(&xen_hvmtimer_syscore_ops);
 }
 #endif

[PATCH 05/11] xen/hvm kexec: unregister debugirq during reboot

[Olaf Hering]

[-- Attachment #1: xen.syscore_ops.unbind.xen_debug_irq.patch --]
[-- Type: text/plain, Size: 1570 bytes --]

Unregister the debugirq during kexec, otherwise the kexec kernel will
run into the BUG() in bind_virq_to_irq() when trying to bind to the
still registered virq.

v2:
 use kexec_is_loaded() function

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 arch/x86/xen/smp.c |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

Index: linux-3.0/arch/x86/xen/smp.c
===================================================================
--- linux-3.0.orig/arch/x86/xen/smp.c
+++ linux-3.0/arch/x86/xen/smp.c
@@ -16,6 +16,8 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/smp.h>
+#include <linux/kexec.h>
+#include <linux/syscore_ops.h>
 
 #include <asm/paravirt.h>
 #include <asm/desc.h>
@@ -45,6 +47,25 @@ static DEFINE_PER_CPU(int, xen_debug_irq
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
 static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
 
+static void xen_hvn_smp_shutdown(void)
+{
+	int cpu;
+
+	if (!kexec_is_loaded())
+		return;
+
+	for_each_online_cpu(cpu) {
+		if (per_cpu(xen_debug_irq, cpu) < 0)
+			continue;
+		unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL);
+		per_cpu(xen_debug_irq, cpu) = -1;
+	}
+}
+
+static struct syscore_ops xen_hvn_smp_syscore_ops = {
+	.shutdown = xen_hvn_smp_shutdown,
+};
+
 /*
  * Reschedule call back.
  */
@@ -525,6 +546,7 @@ static void __init xen_hvm_smp_prepare_c
 		return;
 	xen_init_lock_cpu(0);
 	xen_init_spinlocks();
+	register_syscore_ops(&xen_hvn_smp_syscore_ops);
 }
 
 static int __cpuinit xen_hvm_cpu_up(unsigned int cpu)

[PATCH 06/11] xen/hvm kexec: unregister shutdown+sysrq watches during reboot

[Olaf Hering]

[-- Attachment #1: xen.syscore_ops.unregister_watch.shutdown_event.patch --]
[-- Type: text/plain, Size: 1433 bytes --]

Unregister the shutdown and sysrq watch during kexec.  The watches can
not be re-registered in the kexec kernel because they are still seen as
busy by xenstore.

v2:
 use kexec_is_loaded() function

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 drivers/xen/manage.c |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

Index: linux-3.0/drivers/xen/manage.c
===================================================================
--- linux-3.0.orig/drivers/xen/manage.c
+++ linux-3.0/drivers/xen/manage.c
@@ -8,6 +8,7 @@
 #include <linux/sysrq.h>
 #include <linux/stop_machine.h>
 #include <linux/freezer.h>
+#include <linux/kexec.h>
 #include <linux/syscore_ops.h>
 
 #include <xen/xen.h>
@@ -320,6 +321,21 @@ static int shutdown_event(struct notifie
 	return NOTIFY_DONE;
 }
 
+static void xenbus_manage_shutdown_watcher(void)
+{
+	if (!kexec_is_loaded())
+		return;
+
+	unregister_xenbus_watch(&shutdown_watch);
+#ifdef CONFIG_MAGIC_SYSRQ
+	unregister_xenbus_watch(&sysrq_watch);
+#endif
+}
+
+static struct syscore_ops xenbus_manage_watcher_syscore_ops = {
+	.shutdown = xenbus_manage_shutdown_watcher,
+};
+
 int xen_setup_shutdown_event(void)
 {
 	static struct notifier_block xenstore_notifier = {
@@ -329,6 +345,7 @@ int xen_setup_shutdown_event(void)
 	if (!xen_domain())
 		return -ENODEV;
 	register_xenstore_notifier(&xenstore_notifier);
+	register_syscore_ops(&xenbus_manage_watcher_syscore_ops);
 
 	return 0;
 }

[PATCH 07/11] xen/hvm kexec: unregister memory/target watch in xen-balloon.c

[Olaf Hering]

[-- Attachment #1: xen.syscore_ops.unregister_watch.xen-balloon.patch --]
[-- Type: text/plain, Size: 1376 bytes --]

Unregister the memory/target watch during kexec. The watche can not be
re-registered in the kexec kernel because it is still seen as busy by
xenstore.

v2:
 use kexec_is_loaded() function

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 drivers/xen/xen-balloon.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

Index: linux-3.0/drivers/xen/xen-balloon.c
===================================================================
--- linux-3.0.orig/drivers/xen/xen-balloon.c
+++ linux-3.0/drivers/xen/xen-balloon.c
@@ -34,6 +34,8 @@
 #include <linux/module.h>
 #include <linux/sysdev.h>
 #include <linux/capability.h>
+#include <linux/kexec.h>
+#include <linux/syscore_ops.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -91,6 +93,18 @@ static struct notifier_block xenstore_no
 	.notifier_call = balloon_init_watcher,
 };
 
+static void xen_balloon_shutdown_watcher(void)
+{
+	if (!kexec_is_loaded())
+		return;
+
+	unregister_xenbus_watch(&target_watch);
+}
+
+static struct syscore_ops xen_balloon_watcher_syscore_ops = {
+	.shutdown = xen_balloon_shutdown_watcher,
+};
+
 static int __init balloon_init(void)
 {
 	if (!xen_domain())
@@ -100,6 +114,7 @@ static int __init balloon_init(void)
 
 	register_balloon(&balloon_sysdev);
 	register_xenstore_notifier(&xenstore_notifier);
+	register_syscore_ops(&xen_balloon_watcher_syscore_ops);
 
 	return 0;
 }

[PATCH 08/11] xen/hvm kexec: unregister the watch of the "backend" node during reboot

[Olaf Hering]

[-- Attachment #1: xen.syscore_ops.unregister_watch.xenbus_backend.patch --]
[-- Type: text/plain, Size: 1502 bytes --]

The watch of the xenstore "backend" node has to be unregistered during a
kexec reboot. Otherwise the kexec kernel will crash due to a memory
corruption because more than one watch is registered on that node.

v2:
 use kexec_is_loaded() function

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 drivers/xen/xenbus/xenbus_probe_backend.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

Index: linux-3.0/drivers/xen/xenbus/xenbus_probe_backend.c
===================================================================
--- linux-3.0.orig/drivers/xen/xenbus/xenbus_probe_backend.c
+++ linux-3.0/drivers/xen/xenbus/xenbus_probe_backend.c
@@ -42,6 +42,8 @@
 #include <linux/fcntl.h>
 #include <linux/mm.h>
 #include <linux/notifier.h>
+#include <linux/kexec.h>
+#include <linux/syscore_ops.h>
 
 #include <asm/page.h>
 #include <asm/pgtable.h>
@@ -255,6 +257,18 @@ static int backend_probe_and_watch(struc
 	return NOTIFY_DONE;
 }
 
+static void xenbus_backend_shutdown_watcher(void)
+{
+	if (!kexec_is_loaded())
+		return;
+
+	unregister_xenbus_watch(&be_watch);
+}
+
+static struct syscore_ops xenbus_backend_watcher_syscore_ops = {
+	.shutdown = xenbus_backend_shutdown_watcher,
+};
+
 static int __init xenbus_probe_backend_init(void)
 {
 	static struct notifier_block xenstore_notifier = {
@@ -270,6 +284,7 @@ static int __init xenbus_probe_backend_i
 		return err;
 
 	register_xenstore_notifier(&xenstore_notifier);
+	register_syscore_ops(&xenbus_backend_watcher_syscore_ops);
 
 	return 0;
 }

[PATCH 09/11] xen/hvm kexec: unregister the watch of the "device" node during reboot

[Olaf Hering]

[-- Attachment #1: xen.syscore_ops.unregister_watch.xenbus_frontend.patch --]
[-- Type: text/plain, Size: 1458 bytes --]

The watch of the xenstore "device" node has to be unregistered during a
kexec reboot. Otherwise the kexec kernel will crash due to a memory
corruption because more than one watch is registered on that node.

v2:
 use kexec_is_loaded() function

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 drivers/xen/xenbus/xenbus_probe_frontend.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

Index: linux-3.0/drivers/xen/xenbus/xenbus_probe_frontend.c
===================================================================
--- linux-3.0.orig/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ linux-3.0/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -13,6 +13,8 @@
 #include <linux/kthread.h>
 #include <linux/mutex.h>
 #include <linux/io.h>
+#include <linux/kexec.h>
+#include <linux/syscore_ops.h>
 
 #include <asm/page.h>
 #include <asm/pgtable.h>
@@ -263,6 +265,18 @@ static int frontend_probe_and_watch(stru
 	return NOTIFY_DONE;
 }
 
+static void xenbus_frontend_shutdown_watcher(void)
+{
+	if (!kexec_is_loaded())
+		return;
+
+	unregister_xenbus_watch(&fe_watch);
+}
+
+static struct syscore_ops xenbus_frontend_watcher_syscore_ops = {
+	.shutdown = xenbus_frontend_shutdown_watcher,
+};
+
 
 static int __init xenbus_probe_frontend_init(void)
 {
@@ -279,6 +293,7 @@ static int __init xenbus_probe_frontend_
 		return err;
 
 	register_xenstore_notifier(&xenstore_notifier);
+	register_syscore_ops(&xenbus_frontend_watcher_syscore_ops);
 
 	return 0;
 }

[PATCH 10/11] xen kexec: reset device state to Initializing during reboot

[Olaf Hering]

[-- Attachment #1: xen.xenbus_dev_shutdown.XenbusStateInitialising.patch --]
[-- Type: text/plain, Size: 2243 bytes --]

During kexec all devices will be shutdown, the backend drivers enter the
Closed state. But in this state the kexec kernel can not connect to the
backend because it expects the devices in InitWait state.
After triggering the Closing event, trigger also the Initializing event
and wait until the backend has changed its state. Without this waiting
the kexec kernel may find a device where a state change from Closed to
InitWait is still in progress.

v2:
 unregister the watch on the /local/domain/0/backend/<dev>/<domid>/0/state
 node to avoid memory corruption in the kexec kernel

v3:
 use kexec_is_loaded() function

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 drivers/xen/xenbus/xenbus_probe.c |   25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

Index: linux-3.0/drivers/xen/xenbus/xenbus_probe.c
===================================================================
--- linux-3.0.orig/drivers/xen/xenbus/xenbus_probe.c
+++ linux-3.0/drivers/xen/xenbus/xenbus_probe.c
@@ -46,6 +46,7 @@
 #include <linux/mutex.h>
 #include <linux/io.h>
 #include <linux/slab.h>
+#include <linux/kexec.h>
 
 #include <asm/page.h>
 #include <asm/pgtable.h>
@@ -192,8 +193,19 @@ void xenbus_otherend_changed(struct xenb
 	 * work that can fail e.g., when the rootfs is gone.
 	 */
 	if (system_state > SYSTEM_RUNNING) {
-		if (ignore_on_shutdown && (state == XenbusStateClosing))
-			xenbus_frontend_closed(dev);
+		if (ignore_on_shutdown) {
+			switch (state) {
+			case XenbusStateClosing:
+				xenbus_frontend_closed(dev);
+				break;
+			case XenbusStateInitialising:
+			case XenbusStateInitWait:
+				complete(&dev->down);
+				break;
+			default:
+				break;
+			}
+		}
 		return;
 	}
 
@@ -284,6 +296,15 @@ void xenbus_dev_shutdown(struct device *
 	if (!timeout)
 		printk(KERN_INFO "%s: %s timeout closing device\n",
 		       __func__, dev->nodename);
+
+	if (system_state > SYSTEM_RUNNING && kexec_is_loaded()) {
+		xenbus_switch_state(dev, XenbusStateInitialising);
+		timeout = wait_for_completion_timeout(&dev->down, timeout);
+		if (!timeout)
+			printk(KERN_INFO "%s: %s timeout initializing device\n",
+			       __func__, dev->nodename);
+		free_otherend_watch(dev);
+	}
  out:
 	put_device(&dev->dev);
 }

[PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel

[Olaf Hering]

[-- Attachment #1: xen.pv-on-hvm.kdump.patch --]
[-- Type: text/plain, Size: 4943 bytes --]

(this is actually a forward port of rev 1079 from 2.6.18.hg, untested because
kdump just hangs before (or while) entering the crash kernel in 3.0)

After triggering a crash dump in a HVM guest, the PV backend drivers
will remain in connected state. When the kdump kernel starts the PV
drivers will skip such devices. As a result, no root device is found and
the vmcore cant be saved.

With this change all frontend devices with state XenbusStateConnected
will be reset by changing the state file to Closing/Closed/Initializing.
This will trigger a disconnect in the backend drivers. Now the frontend
drivers will find the backend drivers in state Initwait and can connect.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 drivers/xen/xenbus/xenbus_comms.c          |    4 -
 drivers/xen/xenbus/xenbus_probe_frontend.c |   97 +++++++++++++++++++++++++++++
 2 files changed, 100 insertions(+), 1 deletion(-)

Index: linux-3.0/drivers/xen/xenbus/xenbus_comms.c
===================================================================
--- linux-3.0.orig/drivers/xen/xenbus/xenbus_comms.c
+++ linux-3.0/drivers/xen/xenbus/xenbus_comms.c
@@ -212,7 +212,9 @@ int xb_init_comms(void)
 		printk(KERN_WARNING "XENBUS response ring is not quiescent "
 		       "(%08x:%08x): fixing up\n",
 		       intf->rsp_cons, intf->rsp_prod);
-		intf->rsp_cons = intf->rsp_prod;
+		/* breaks kdump */
+		if (!reset_devices)
+			intf->rsp_cons = intf->rsp_prod;
 	}
 
 	if (xenbus_irq) {
Index: linux-3.0/drivers/xen/xenbus/xenbus_probe_frontend.c
===================================================================
--- linux-3.0.orig/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ linux-3.0/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -254,10 +254,107 @@ int __xenbus_register_frontend(struct xe
 }
 EXPORT_SYMBOL_GPL(__xenbus_register_frontend);
 
+#ifdef CONFIG_CRASH_DUMP
+static DECLARE_WAIT_QUEUE_HEAD(be_state_wq);
+static int be_state;
+
+static void xenbus_reset_state_changed(struct xenbus_watch *w, const char **v, unsigned int l)
+{
+	xenbus_scanf(XBT_NIL, v[XS_WATCH_PATH], "", "%i", &be_state);
+	printk(KERN_INFO "XENBUS: %s %s\n", v[XS_WATCH_PATH], xenbus_strstate(be_state));
+	wake_up(&be_state_wq);
+}
+
+static int xenbus_reset_check_final(int *st)
+{
+	return *st == XenbusStateInitialising || *st == XenbusStateInitWait;
+}
+
+static void xenbus_reset_frontend_state(char *backend, char *frontend)
+{
+	struct xenbus_watch watch;
+
+	memset(&watch, 0, sizeof(watch));
+	watch.node = kasprintf(GFP_NOIO | __GFP_HIGH, "%s/state", backend);
+	if (!watch.node)
+		return;
+
+	watch.callback = xenbus_reset_state_changed;
+	be_state = XenbusStateUnknown;
+
+	printk(KERN_INFO "XENBUS: triggering reconnect on %s\n", backend);
+	register_xenbus_watch(&watch);
+
+	xenbus_printf(XBT_NIL, frontend, "state", "%d", XenbusStateClosing);
+	wait_event_interruptible(be_state_wq, be_state == XenbusStateClosing);
+
+	xenbus_printf(XBT_NIL, frontend, "state", "%d", XenbusStateClosed);
+	wait_event_interruptible(be_state_wq, be_state == XenbusStateClosed);
+
+	xenbus_printf(XBT_NIL, frontend, "state", "%d", XenbusStateInitialising);
+	wait_event_interruptible(be_state_wq, xenbus_reset_check_final(&be_state));
+
+	unregister_xenbus_watch(&watch);
+	printk(KERN_INFO "XENBUS: reconnect done on %s\n", backend);
+	kfree(watch.node);
+}
+
+static void xenbus_reset_check_state(char *class, char *dev)
+{
+	int state, err;
+	char *backend, *frontend;
+
+	frontend = kasprintf(GFP_NOIO | __GFP_HIGH, "device/%s/%s", class, dev);
+	if (!frontend)
+		return;
+
+	err = xenbus_scanf(XBT_NIL, frontend, "state", "%i", &state);
+	/* frontend connected? */
+	if (err == 1 && state == XenbusStateConnected) {
+		backend = xenbus_read(XBT_NIL, frontend, "backend", NULL);
+		if (!backend || IS_ERR(backend))
+			goto out;
+		err = xenbus_scanf(XBT_NIL, backend, "state", "%i", &state);
+		/* backend connected? */
+		if (err == 1 && state == XenbusStateConnected)
+			xenbus_reset_frontend_state(backend, frontend);
+		kfree(backend);
+	}
+out:
+	kfree(frontend);
+}
+
+static void xenbus_reset_state(void)
+{
+	char **devclass, **dev;
+	int devclass_n, dev_n;
+	int i, j;
+
+	devclass = xenbus_directory(XBT_NIL, "device", "", &devclass_n);
+	if (IS_ERR(devclass))
+		return;
+
+	for (i = 0; i < devclass_n; i++) {
+		dev = xenbus_directory(XBT_NIL, "device", devclass[i], &dev_n);
+		if (IS_ERR(dev))
+			continue;
+		for (j = 0; j < dev_n; j++)
+			xenbus_reset_check_state(devclass[i], dev[j]);
+		kfree(dev);
+	}
+	kfree(devclass);
+}
+#endif
+
 static int frontend_probe_and_watch(struct notifier_block *notifier,
 				   unsigned long event,
 				   void *data)
 {
+#ifdef CONFIG_CRASH_DUMP
+	/* reset devices in XenbusStateConnected state */
+	if (!xen_initial_domain() && reset_devices)
+		xenbus_reset_state();
+#endif
 	/* Enumerate devices in xenstore and watch for changes. */
 	xenbus_probe_devices(&xenbus_frontend);
 	register_xenbus_watch(&fe_watch);

Re: [PATCH 00/11] [v2] misc changes for kexec in pv-on-hvm guests

[Keir Fraser]

On 28/07/2011 14:23, "Olaf Hering" <olaf@aepfle.de> wrote:

> A fixed kexec-tools-2.0.2 package is required:
> http://lists.infradead.org/pipermail/kexec/2011-May/005026.html
> However, as I just found out, xenfs unconditionally adds
> /proc/xen/capabilities
> even for hvm guest.
> 
> So: how is a hvm guest supposed to be detected in 3.0?

Rip the moving parts from tools/misc/xen-detect.c. It does rely on hooking
SIGILL if you want to safely probe for being a PV guest (uses a
paravirtualised CPUID instruction that is normally an illegal instruction).

 -- Keir

Re: [PATCH 01/11] kexec: add kexec_is_loaded function

[Stefano Stabellini]

On Thu, 28 Jul 2011, Olaf Hering wrote:
> Add a new function kexec_is_loaded to be used by subsequent changes for
> kexec in Xen HVM guests with PV drivers loaded.
> 
> A kexec reboot in a HVM guest needs to unregister all resources such as
> xenstore watches and virqs, otherwise the kexec kernel can not bind to
> these resources again. But the unregister only needs to happen during a
> kexec boot because the guest remains the same from the Xen point of
> view. A normal reboot will shutdown and destroy the entire guest with
> all its resources, then the guest will start again with a different
> domain_id number. So doing all the unregister work would only delay
> normal reboots.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> ---
>  include/linux/kexec.h |    3 ++-
>  kernel/kexec.c        |    8 +++++++-
>  kernel/ksysfs.c       |    2 +-
>  3 files changed, 10 insertions(+), 3 deletions(-)
> 
> Index: linux-3.0/include/linux/kexec.h
> ===================================================================
> --- linux-3.0.orig/include/linux/kexec.h
> +++ linux-3.0/include/linux/kexec.h
> @@ -126,6 +126,7 @@ extern asmlinkage long compat_sys_kexec_
>  extern struct page *kimage_alloc_control_pages(struct kimage *image,
>  						unsigned int order);
>  extern void crash_kexec(struct pt_regs *);
> +extern int kexec_is_loaded(void);
>  int kexec_should_crash(struct task_struct *);
>  void crash_save_cpu(struct pt_regs *regs, int cpu);
>  void crash_save_vmcoreinfo(void);
> @@ -156,7 +157,6 @@ unsigned long paddr_vmcoreinfo_note(void
>  #define VMCOREINFO_CONFIG(name) \
>  	vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
>  
> -extern struct kimage *kexec_image;
>  extern struct kimage *kexec_crash_image;
>  
>  #ifndef kexec_flush_icache_page
> @@ -214,6 +214,7 @@ void crash_free_reserved_phys_range(unsi
>  struct pt_regs;
>  struct task_struct;
>  static inline void crash_kexec(struct pt_regs *regs) { }
> +static inline int kexec_is_loaded(void) { return 0; }
>  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
>  #endif /* CONFIG_KEXEC */
>  #endif /* LINUX_KEXEC_H */
> Index: linux-3.0/kernel/kexec.c
> ===================================================================
> --- linux-3.0.orig/kernel/kexec.c
> +++ linux-3.0/kernel/kexec.c
> @@ -934,7 +934,7 @@ static int kimage_load_segment(struct ki
>   * kexec does not sync, or unmount filesystems so if you need
>   * that to happen you need to do that yourself.
>   */
> -struct kimage *kexec_image;
> +static struct kimage *kexec_image;
>  struct kimage *kexec_crash_image;
>  
>  static DEFINE_MUTEX(kexec_mutex);
> @@ -1567,3 +1567,9 @@ int kernel_kexec(void)
>  	mutex_unlock(&kexec_mutex);
>  	return error;
>  }
> +
> +int kexec_is_loaded(void)
> +{
> +	return !!kexec_image;
> +}
> +EXPORT_SYMBOL_GPL(kexec_is_loaded);

Wouldn't this return true just if a kexec_image is loaded no matter if
this is a normal shutdown or if it is an actually kexec reboot?

Re: [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel

[Stefano Stabellini]

On Thu, 28 Jul 2011, Olaf Hering wrote:
> (this is actually a forward port of rev 1079 from 2.6.18.hg, untested because
> kdump just hangs before (or while) entering the crash kernel in 3.0)
> 
> After triggering a crash dump in a HVM guest, the PV backend drivers
> will remain in connected state. When the kdump kernel starts the PV
> drivers will skip such devices. As a result, no root device is found and
> the vmcore cant be saved.
> 
> With this change all frontend devices with state XenbusStateConnected
> will be reset by changing the state file to Closing/Closed/Initializing.
> This will trigger a disconnect in the backend drivers. Now the frontend
> drivers will find the backend drivers in state Initwait and can connect.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> ---
>  drivers/xen/xenbus/xenbus_comms.c          |    4 -
>  drivers/xen/xenbus/xenbus_probe_frontend.c |   97 +++++++++++++++++++++++++++++
>  2 files changed, 100 insertions(+), 1 deletion(-)
> 
> Index: linux-3.0/drivers/xen/xenbus/xenbus_comms.c
> ===================================================================
> --- linux-3.0.orig/drivers/xen/xenbus/xenbus_comms.c
> +++ linux-3.0/drivers/xen/xenbus/xenbus_comms.c
> @@ -212,7 +212,9 @@ int xb_init_comms(void)
>  		printk(KERN_WARNING "XENBUS response ring is not quiescent "
>  		       "(%08x:%08x): fixing up\n",
>  		       intf->rsp_cons, intf->rsp_prod);
> -		intf->rsp_cons = intf->rsp_prod;
> +		/* breaks kdump */
> +		if (!reset_devices)
> +			intf->rsp_cons = intf->rsp_prod;
>  	}

Where is reset_devices coming from?
I hope is set only on a kexec reboot.

Considering that all the other patches in this series follow the
opposite strategy, that is closing stuff on shutdown, why are you trying
to close xenbus connections on boot here?
At this point I would rather be coherent and simply switch to
XenbusStateClosing or XenbusStateClosed in the shutdown path if
kexec_is_loaded.

Re: [PATCH 01/11] kexec: add kexec_is_loaded function

[Konrad Rzeszutek Wilk]

On Fri, Jul 29, 2011 at 03:45:23PM +0100, Stefano Stabellini wrote:
> On Thu, 28 Jul 2011, Olaf Hering wrote:
> > Add a new function kexec_is_loaded to be used by subsequent changes for
> > kexec in Xen HVM guests with PV drivers loaded.

.. which is called 'PVonHVM'
> > 
> > A kexec reboot in a HVM guest needs to unregister all resources such as

Not HVM - PVonHVM.
> > xenstore watches and virqs, otherwise the kexec kernel can not bind to
> > these resources again. But the unregister only needs to happen during a
> > kexec boot because the guest remains the same from the Xen point of
> > view. A normal reboot will shutdown and destroy the entire guest with
> > all its resources, then the guest will start again with a different
> > domain_id number. So doing all the unregister work would only delay
> > normal reboots.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>

You need to CC the maintainers of these files too.
> > 
> > ---
> >  include/linux/kexec.h |    3 ++-
> >  kernel/kexec.c        |    8 +++++++-
> >  kernel/ksysfs.c       |    2 +-
> >  3 files changed, 10 insertions(+), 3 deletions(-)
> > 
> > Index: linux-3.0/include/linux/kexec.h
> > ===================================================================
> > --- linux-3.0.orig/include/linux/kexec.h
> > +++ linux-3.0/include/linux/kexec.h

And make sure to use git format-patch to come up with the patches.

> > @@ -126,6 +126,7 @@ extern asmlinkage long compat_sys_kexec_
> >  extern struct page *kimage_alloc_control_pages(struct kimage *image,
> >  						unsigned int order);
> >  extern void crash_kexec(struct pt_regs *);
> > +extern int kexec_is_loaded(void);
> >  int kexec_should_crash(struct task_struct *);
> >  void crash_save_cpu(struct pt_regs *regs, int cpu);
> >  void crash_save_vmcoreinfo(void);
> > @@ -156,7 +157,6 @@ unsigned long paddr_vmcoreinfo_note(void
> >  #define VMCOREINFO_CONFIG(name) \
> >  	vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
> >  
> > -extern struct kimage *kexec_image;
> >  extern struct kimage *kexec_crash_image;
> >  
> >  #ifndef kexec_flush_icache_page
> > @@ -214,6 +214,7 @@ void crash_free_reserved_phys_range(unsi
> >  struct pt_regs;
> >  struct task_struct;
> >  static inline void crash_kexec(struct pt_regs *regs) { }
> > +static inline int kexec_is_loaded(void) { return 0; }
> >  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
> >  #endif /* CONFIG_KEXEC */
> >  #endif /* LINUX_KEXEC_H */
> > Index: linux-3.0/kernel/kexec.c
> > ===================================================================
> > --- linux-3.0.orig/kernel/kexec.c
> > +++ linux-3.0/kernel/kexec.c
> > @@ -934,7 +934,7 @@ static int kimage_load_segment(struct ki
> >   * kexec does not sync, or unmount filesystems so if you need
> >   * that to happen you need to do that yourself.
> >   */
> > -struct kimage *kexec_image;
> > +static struct kimage *kexec_image;
> >  struct kimage *kexec_crash_image;
> >  
> >  static DEFINE_MUTEX(kexec_mutex);
> > @@ -1567,3 +1567,9 @@ int kernel_kexec(void)
> >  	mutex_unlock(&kexec_mutex);
> >  	return error;
> >  }
> > +
> > +int kexec_is_loaded(void)
> > +{
> > +	return !!kexec_image;
> > +}
> > +EXPORT_SYMBOL_GPL(kexec_is_loaded);
> 
> Wouldn't this return true just if a kexec_image is loaded no matter if
> this is a normal shutdown or if it is an actually kexec reboot?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH 00/11] [v2] misc changes for kexec in pv-on-hvm guests

[Konrad Rzeszutek Wilk]

On Thu, Jul 28, 2011 at 03:23:00PM +0200, Olaf Hering wrote:
> 
> 
> The following series implement kexec in a pv-on-hvm guest.
> I send it here once more for further review before bothering lkml.

Ah, OK. Ignore my comment about attaching the other maintainers to
the patch then.
> 
> With this series doing kexec in a loop is now possible.
> 
> 
> A fixed kexec-tools-2.0.2 package is required:
> http://lists.infradead.org/pipermail/kexec/2011-May/005026.html
> However, as I just found out, xenfs unconditionally adds /proc/xen/capabilities
> even for hvm guest.
> 
> So: how is a hvm guest supposed to be detected in 3.0?

A real "HVM" or PVonHVM?

What about following the syntax of 'xen-detect' which does an cpuid
instruction.

> 
> Olaf
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH 05/11] xen/hvm kexec: unregister debugirq during reboot

[Konrad Rzeszutek Wilk]

On Thu, Jul 28, 2011 at 03:23:05PM +0200, Olaf Hering wrote:
> Unregister the debugirq during kexec, otherwise the kexec kernel will
> run into the BUG() in bind_virq_to_irq() when trying to bind to the
> still registered virq.
> 
> v2:
>  use kexec_is_loaded() function

Is that really neccessary? I mean can you just do it without checking for
that? As in, if you don't have a kexec kernel loaded what will happend to
the guest?

> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> ---
>  arch/x86/xen/smp.c |   22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> Index: linux-3.0/arch/x86/xen/smp.c
> ===================================================================
> --- linux-3.0.orig/arch/x86/xen/smp.c
> +++ linux-3.0/arch/x86/xen/smp.c
> @@ -16,6 +16,8 @@
>  #include <linux/err.h>
>  #include <linux/slab.h>
>  #include <linux/smp.h>
> +#include <linux/kexec.h>
> +#include <linux/syscore_ops.h>
>  
>  #include <asm/paravirt.h>
>  #include <asm/desc.h>
> @@ -45,6 +47,25 @@ static DEFINE_PER_CPU(int, xen_debug_irq
>  static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
>  static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
>  
> +static void xen_hvn_smp_shutdown(void)
> +{
> +	int cpu;
> +
> +	if (!kexec_is_loaded())
> +		return;
> +
> +	for_each_online_cpu(cpu) {
> +		if (per_cpu(xen_debug_irq, cpu) < 0)
> +			continue;
> +		unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL);
> +		per_cpu(xen_debug_irq, cpu) = -1;
> +	}
> +}
> +
> +static struct syscore_ops xen_hvn_smp_syscore_ops = {
> +	.shutdown = xen_hvn_smp_shutdown,
> +};
> +
>  /*
>   * Reschedule call back.
>   */
> @@ -525,6 +546,7 @@ static void __init xen_hvm_smp_prepare_c
>  		return;
>  	xen_init_lock_cpu(0);
>  	xen_init_spinlocks();
> +	register_syscore_ops(&xen_hvn_smp_syscore_ops);
>  }
>  
>  static int __cpuinit xen_hvm_cpu_up(unsigned int cpu)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel

[Olaf Hering]

On Fri, Jul 29, Stefano Stabellini wrote:

> On Thu, 28 Jul 2011, Olaf Hering wrote:
> > (this is actually a forward port of rev 1079 from 2.6.18.hg, untested because
> > kdump just hangs before (or while) entering the crash kernel in 3.0)
> > 
> > After triggering a crash dump in a HVM guest, the PV backend drivers
> > will remain in connected state. When the kdump kernel starts the PV
> > drivers will skip such devices. As a result, no root device is found and
> > the vmcore cant be saved.
> > 
> > With this change all frontend devices with state XenbusStateConnected
> > will be reset by changing the state file to Closing/Closed/Initializing.
> > This will trigger a disconnect in the backend drivers. Now the frontend
> > drivers will find the backend drivers in state Initwait and can connect.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > 
> > ---
> >  drivers/xen/xenbus/xenbus_comms.c          |    4 -
> >  drivers/xen/xenbus/xenbus_probe_frontend.c |   97 +++++++++++++++++++++++++++++
> >  2 files changed, 100 insertions(+), 1 deletion(-)
> > 
> > Index: linux-3.0/drivers/xen/xenbus/xenbus_comms.c
> > ===================================================================
> > --- linux-3.0.orig/drivers/xen/xenbus/xenbus_comms.c
> > +++ linux-3.0/drivers/xen/xenbus/xenbus_comms.c
> > @@ -212,7 +212,9 @@ int xb_init_comms(void)
> >  		printk(KERN_WARNING "XENBUS response ring is not quiescent "
> >  		       "(%08x:%08x): fixing up\n",
> >  		       intf->rsp_cons, intf->rsp_prod);
> > -		intf->rsp_cons = intf->rsp_prod;
> > +		/* breaks kdump */
> > +		if (!reset_devices)
> > +			intf->rsp_cons = intf->rsp_prod;
> >  	}
> 
> Where is reset_devices coming from?
> I hope is set only on a kexec reboot.

This is for a kdump boot, its added as additional kernel cmdline option
for the kdump kernel.

> Considering that all the other patches in this series follow the
> opposite strategy, that is closing stuff on shutdown, why are you trying
> to close xenbus connections on boot here?
> At this point I would rather be coherent and simply switch to
> XenbusStateClosing or XenbusStateClosed in the shutdown path if
> kexec_is_loaded.

To allow the kdump kernel to store the /proc/vmcore file somewhere, it
has to get either storage or network access.  But the kdump kernel finds
all devices in the Connected state, because the to-be-debugged kernel
just crashed. So it has to reset the connection to the backend.

Olaf

Re: [PATCH 01/11] kexec: add kexec_is_loaded function

[Olaf Hering]

On Fri, Jul 29, Konrad Rzeszutek Wilk wrote:

> > > +int kexec_is_loaded(void)
> > > +{
> > > +	return !!kexec_image;
> > > +}
> > > +EXPORT_SYMBOL_GPL(kexec_is_loaded);
> > 
> > Wouldn't this return true just if a kexec_image is loaded no matter if
> > this is a normal shutdown or if it is an actually kexec reboot?

This patch is not needed if every cleanup is done right during bootup.
See the 3rd version of my kexec/kdump patch which I sent out today.

Olaf

Re: [PATCH 00/11] [v2] misc changes for kexec in pv-on-hvm guests

[Olaf Hering]

On Thu, Jul 28, Keir Fraser wrote:

> On 28/07/2011 14:23, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > A fixed kexec-tools-2.0.2 package is required:
> > http://lists.infradead.org/pipermail/kexec/2011-May/005026.html
> > However, as I just found out, xenfs unconditionally adds
> > /proc/xen/capabilities
> > even for hvm guest.
> > 
> > So: how is a hvm guest supposed to be detected in 3.0?
> 
> Rip the moving parts from tools/misc/xen-detect.c. It does rely on hooking
> SIGILL if you want to safely probe for being a PV guest (uses a
> paravirtualised CPUID instruction that is normally an illegal instruction).

Thanks, I will work on a better kexec-tools patch to distinguish dom0
from a PVonHVM guest.

Olaf

Re: [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel

[Stefano Stabellini]

On Mon, 1 Aug 2011, Olaf Hering wrote:
> > Considering that all the other patches in this series follow the
> > opposite strategy, that is closing stuff on shutdown, why are you trying
> > to close xenbus connections on boot here?
> > At this point I would rather be coherent and simply switch to
> > XenbusStateClosing or XenbusStateClosed in the shutdown path if
> > kexec_is_loaded.
> 
> To allow the kdump kernel to store the /proc/vmcore file somewhere, it
> has to get either storage or network access.  But the kdump kernel finds
> all devices in the Connected state, because the to-be-debugged kernel
> just crashed. So it has to reset the connection to the backend.
 
my point still stands: why are you doing it on kdump boot rather than
doing it on the shutdown path?
It would be more coherent with the other patches in the series.

Where can I find current (and up to date) documentation for xen 4.1.1?

[Mark Schneider]

Hello

After installing xen-docs-4.1 debian package (s. below) I was expecting 
an "up to date" documentation for xen 4.1.1.
# ---
ii  xen-docs-4.1                         
4.1.1-1                           Documentation for Xen
# ---

Two of three .pdf files (interface.pdf/user.pdf) show at the first page 
xen 3.0 or 3.3.
Does anything has changed for xen 4.1.1? .. or maybe the only 
documentation source is just xen-wiki?

Thank you in advance for any hints.

Regards, Mark

-- 
ms@it-infrastrukturen.org

xen 4.1.1 - errors in xend-debug.log: cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory

[Mark Schneider]

Hello,

Why there are many error entries in xend-debug.log (s. below)?

# ---
root@xen41dom0:/var/log/xen# xm info
host                   : xen41dom0
release                : 3.0.0-rc7
version                : #3 SMP Sat Jul 16 00:01:14 CEST 2011
machine                : x86_64
nr_cpus                : 24
nr_nodes               : 4
cores_per_socket       : 12
threads_per_core       : 1
cpu_mhz                : 2500
hw_caps                : 
178bf3ff:efd3fbff:00000000:00001710:00802001:00000000:000837ff:00000000
virt_caps              : hvm
total_memory           : 32763
free_memory            : 30868
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_mem=1536M iommu=1
cc_compiler            : gcc version 4.6.1 (Debian 4.6.1-4)
cc_compile_by          : waldi
cc_compile_domain      : debian.org
cc_compile_date        : Mon Jul 18 17:41:10 UTC 2011
xend_config_format     : 4
# ---

Thank you in advance for any hints.

Regards
Mark

-- 
ms@it-infrastrukturen.org

# ---
root@xen41dom0:/var/log/xen# cat xend-debug.log
Xend started at Tue Aug  2 20:54:31 2011.
cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host0/model: No such file or directory
cat: /sys/bus/scsi/devices/host0/type: No such file or directory
cat: /sys/bus/scsi/devices/host0/rev: No such file or directory
cat: /sys/bus/scsi/devices/host0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host1/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host1/model: No such file or directory
cat: /sys/bus/scsi/devices/host1/type: No such file or directory
cat: /sys/bus/scsi/devices/host1/rev: No such file or directory
cat: /sys/bus/scsi/devices/host1/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host2/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host2/model: No such file or directory
cat: /sys/bus/scsi/devices/host2/type: No such file or directory
cat: /sys/bus/scsi/devices/host2/rev: No such file or directory
cat: /sys/bus/scsi/devices/host2/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host3/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host3/model: No such file or directory
cat: /sys/bus/scsi/devices/host3/type: No such file or directory
cat: /sys/bus/scsi/devices/host3/rev: No such file or directory
cat: /sys/bus/scsi/devices/host3/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host4/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host4/model: No such file or directory
cat: /sys/bus/scsi/devices/host4/type: No such file or directory
cat: /sys/bus/scsi/devices/host4/rev: No such file or directory
cat: /sys/bus/scsi/devices/host4/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target4:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target4:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target4:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target4:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target4:0:0/scsi_level: No such file or directory
/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendAPI.py:551: DeprecationWarning: object.__new__() takes no parameters
   return object.__new__(cls, *args, **kwds)

[2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: VBD.set_device not found

[Mark Schneider]

Should I worry about the following "WARNING (XendAPI:708) API call" 
entries in xend.log? (s. below)
xen 4.1.1 / debian wheezy kernel 3.0.0-rc7

# ---
root@xen41dom0:/var/log/xen# cat xend.log
[2011-08-02 20:54:31 2721] INFO (SrvDaemon:332) Xend Daemon started
[2011-08-02 20:54:31 2721] INFO (SrvDaemon:336) Xend changeset: unavailable.
[2011-08-02 20:54:36 2721] DEBUG (XendNode:332) pscsi record count: 13
[2011-08-02 20:54:36 2721] DEBUG (XendCPUPool:747) recreate_active_pools
[2011-08-02 20:54:36 2721] DEBUG (XendDomainInfo:151) 
XendDomainInfo.recreate({'max_vcpu_id': 23, 'cpu_time': 86044496632L, 
'ssidref': 0, 'hvm': 0, 'shutdown_reason': 255, 'dying': 0, 
'online_vcpus': 24, 'domid': 0, 'paused': 0, 'crashed': 0, 'running': 1, 
'maxmem_kb': 17179869180L, 'shutdown': 0, 'mem_kb': 1572864L, 'blocked': 
0, 'handle': [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 
'cpupool': 0, 'name': 'Domain-0'})
[2011-08-02 20:54:36 2721] INFO (XendDomainInfo:169) Recreating domain 
0, UUID 00000000-0000-0000-0000-000000000000. at /local/domain/0
[2011-08-02 20:54:36 2721] DEBUG (XendDomainInfo:3420) Storing VM 
details: {'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 
'shadow_memory': '0', 'uuid': '00000000-0000-0000-0000-000000000000', 
'on_reboot': 'restart', 'image': "(linux (kernel '') (superpages 0) 
(nomigrate 0) (tsc_mode 0))", 'on_poweroff': 'destroy', 
'bootloader_args': '', 'on_xend_start': 'ignore', 'on_crash': 'restart', 
'xend/restart_count': '0', 'vcpus': '24', 'vcpu_avail': '16777215', 
'bootloader': '', 'name': 'Domain-0'}
[2011-08-02 20:54:36 2721] DEBUG (XendDomainInfo:1794) Storing domain 
details: {'cpu/3/availability': 'online', 'cpu/6/availability': 
'online', 'vm': '/vm/00000000-0000-0000-0000-000000000000', 
'cpu/22/availability': 'online', 
'control/platform-feature-multiprocessor-suspend': '1', 
'cpu/17/availability': 'online', 'cpu/14/availability': 'online', 
'console/limit': '1048576', 'cpu/2/availability': 'online', 
'cpu/11/availability': 'online', 'cpu/1/availability': 'online', 
'cpu/7/availability': 'online', 'memory/target': '1572864', 
'cpu/20/availability': 'online', 'cpu/4/availability': 'online', 
'cpu/15/availability': 'online', 'description': '', 
'cpu/13/availability': 'online', 'cpu/8/availability': 'online', 
'cpu/9/availability': 'online', 'cpu/5/availability': 'online', 
'cpu/23/availability': 'online', 'cpu/0/availability': 'online', 
'cpu/18/availability': 'online', 'console/type': 'xenconsoled', 
'cpu/12/availability': 'online', 'cpu/19/availability': 'online', 
'name': 'Domain-0', 'domid': '0', 'cpu/16/availability': 'online', 
'cpu/21/availability': 'online', 'cpu/10/availability': 'online'}
[2011-08-02 20:54:36 2721] DEBUG (XendDomain:476) Adding Domain: 0
[2011-08-02 20:54:36 2721] DEBUG (XendDomain:410) number of vcpus to use 
is 0
[2011-08-02 20:54:36 2721] DEBUG (XendDomainInfo:1881) 
XendDomainInfo.handleShutdownWatch
[2011-08-02 20:54:36 2721] INFO (SrvServer:184) unix 
path=/var/lib/xend/xend-socket
[2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: 
VBD.set_device not found
[2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: VBD.set_type 
not found
[2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: 
session.get_all_records not found
[2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: 
event.get_record not found
[2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: event.get_all 
not found
[2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: 
VIF.set_device not found
[2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: VIF.set_MAC 
not found
[2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: VIF.set_MTU 
not found
[2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: debug.get_all 
not found
[2011-08-02 20:54:36 2721] INFO (XMLRPCServer:161) Opening Unix domain 
socket XML-RPC server on /var/run/xend/xmlrpc.sock.
[2011-08-02 20:54:36 2721] INFO (XMLRPCServer:161) Opening Unix domain 
socket XML-RPC server on /var/run/xend/xen-api.sock; authentication has 
been disabled for this server.
# ---

Thank you / regards,
Mark

-- 
ms@it-infrastrukturen.org

xen 4.1.1 - Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

[Mark Schneider]

[-- Attachment #1: Type: text/plain, Size: 3917 bytes --]

Hello,

I need your kindly help. I am getting an error message when trying 
create an HVM on xen 4.1.1 (debian wheezy with kernel 3.0.0-rc7) (s. 
more details below and attached log files). The same config works as 
expected on xen 4.0 (debian sqeueeze). In both cases dom0 runs in live 
mode from an USB-stick.

# ---
root@xen41dom0:/etc/xen# xm create /etc/xen/hvm-wheezyD.born2b3.net.cfg
Using config file "/etc/xen/hvm-wheezyD.born2b3.net.cfg".
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
# ---

Some details:
# ---
root@xen41dom0:/var/log/xen# ln -s /usr/lib/xen-4.1 /usr/lib/xen

root@xen41dom0:/var/log/xen# modprobe -l | grep xen-gnt
kernel/drivers/xen/xen-gntdev.ko
kernel/drivers/xen/xen-gntalloc.ko

xenfs on /proc/xen type xenfs (rw)
/dev/mapper/vg_depos-ftp on /ftp type ext4 (rw)
# ---

# ---
root@xen41dom0:/etc/xen/scripts# xm list
Name                                        ID   Mem VCPUs      State   
Time(s)
Domain-0                                     0  1536    24     r-----    
456.3
wheezyhvm.born2b3.net                        1  8192     1     
--p---      0.0

root@xen41dom0:/etc/xen/scripts# xm list
Name                                        ID   Mem VCPUs      State   
Time(s)
Domain-0                                     0  1536    24     r-----    
465.6
# ---

# ---
root@xen41dom0:/etc/xen# sed -n '/^[a-z]/p' hvm-wheezyD.born2b3.net.cfg
kernel      = '/usr/lib64/xen-default/boot/hvmloader'
builder     = 'hvm'
device_model= '/usr/lib64/xen-4.1/bin/qemu-dm'
name        = 'wheezyhvm.born2b3.net'
acpi        = 1
apic        = 1
vif         = ['bridge=eth0']
disk        = [ 
'phy:/dev/vg_wheezy/wheezy,ioemu:hda,w','file:/ftp/debian-testing-amd64-DVD-1.iso,ioemu:hdc:cdrom,r']
vcpus       = '8'
memory      = '8192'
boot        = 'cd'
vnc         = 1
vncviewer   = 1
vncdisplay  = 9
serial      = 'pty'
usb         = 1
usbdevice   = 'tablet'
# ---

# ---
root@xen41dom0:/# tar cvpf var-log-xen-logs-before-first-xm-create.tar 
var/log/xen/
var/log/xen/
var/log/xen/xend.log
var/log/xen/xend-debug.log
var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log
var/log/xen/xen-hotplug.log
# ---

modprobe xen-gntdev

root@xen41dom0:/etc/xen# xm create /etc/xen/hvm-wheezyD.born2b3.net.cfg
Using config file "/etc/xen/hvm-wheezyD.born2b3.net.cfg".
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

# ---
root@xen41dom0:/# tar cvpf var-log-xen-logs-AFTER-first-xm-create.tar var/log/xen/
var/log/xen/
var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log
var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log.1
var/log/xen/xend.log
var/log/xen/xend-debug.log
var/log/xen/xen-hotplug.log
# ---


What do I miss? Thank you in advance for any hints.

regards, Mark

-- 
ms@it-infrastrukturen.org

# ---
root@xen41dom0:/var/log/xen# xm info
host                   : xen41dom0
release                : 3.0.0-rc7
version                : #3 SMP Sat Jul 16 00:01:14 CEST 2011
machine                : x86_64
nr_cpus                : 24
nr_nodes               : 4
cores_per_socket       : 12
threads_per_core       : 1
cpu_mhz                : 2500
hw_caps                : 178bf3ff:efd3fbff:00000000:00001710:00802001:00000000:000837ff:00000000
virt_caps              : hvm
total_memory           : 32763
free_memory            : 30868
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_mem=1536M iommu=1
cc_compiler            : gcc version 4.6.1 (Debian 4.6.1-4)
cc_compile_by          : waldi
cc_compile_domain      : debian.org
cc_compile_date        : Mon Jul 18 17:41:10 UTC 2011
xend_config_format     : 4



[-- Attachment #2: var-log-xen-logs-before-first-xm-create.tar.gz --]
[-- Type: application/gzip, Size: 1284 bytes --]

[-- Attachment #3: var-log-xen-logs-AFTER-first-xm-create.tar.gz --]
[-- Type: application/gzip, Size: 4759 bytes --]

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: xen 4.1.1 - Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 4556 bytes --]

What is your  GCC version ?

Boris.

--- On Tue, 8/2/11, Mark Schneider <ms@it-infrastrukturen.org> wrote:

From: Mark Schneider <ms@it-infrastrukturen.org>
Subject: [Xen-devel] xen 4.1.1 - Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
To: xen-devel@lists.xensource.com
Date: Tuesday, August 2, 2011, 7:29 PM

Hello,

I need your kindly help. I am getting an error message when trying create an HVM on xen 4.1.1 (debian wheezy with kernel 3.0.0-rc7) (s. more details below and attached log files). The same config works as expected on xen 4.0 (debian sqeueeze). In both cases dom0 runs in live mode from an USB-stick.

# ---
root@xen41dom0:/etc/xen# xm create /etc/xen/hvm-wheezyD.born2b3.net.cfg
Using config file "/etc/xen/hvm-wheezyD.born2b3.net.cfg".
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
# ---

Some details:
# ---
root@xen41dom0:/var/log/xen# ln -s /usr/lib/xen-4.1 /usr/lib/xen

root@xen41dom0:/var/log/xen# modprobe -l | grep xen-gnt
kernel/drivers/xen/xen-gntdev.ko
kernel/drivers/xen/xen-gntalloc.ko

xenfs on /proc/xen type xenfs (rw)
/dev/mapper/vg_depos-ftp on /ftp type ext4 (rw)
# ---

# ---
root@xen41dom0:/etc/xen/scripts# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  1536    24     r-----    456.3
wheezyhvm.born2b3.net                        1  8192     1     --p---      0.0

root@xen41dom0:/etc/xen/scripts# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  1536    24     r-----    465.6
# ---

# ---
root@xen41dom0:/etc/xen# sed -n '/^[a-z]/p' hvm-wheezyD.born2b3.net.cfg
kernel      = '/usr/lib64/xen-default/boot/hvmloader'
builder     = 'hvm'
device_model= '/usr/lib64/xen-4.1/bin/qemu-dm'
name        = 'wheezyhvm.born2b3.net'
acpi        = 1
apic        = 1
vif         = ['bridge=eth0']
disk        = [ 'phy:/dev/vg_wheezy/wheezy,ioemu:hda,w','file:/ftp/debian-testing-amd64-DVD-1.iso,ioemu:hdc:cdrom,r']
vcpus       = '8'
memory      = '8192'
boot        = 'cd'
vnc         = 1
vncviewer   = 1
vncdisplay  = 9
serial      = 'pty'
usb         = 1
usbdevice   = 'tablet'
# ---

# ---
root@xen41dom0:/# tar cvpf var-log-xen-logs-before-first-xm-create.tar var/log/xen/
var/log/xen/
var/log/xen/xend.log
var/log/xen/xend-debug.log
var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log
var/log/xen/xen-hotplug.log
# ---

modprobe xen-gntdev

root@xen41dom0:/etc/xen# xm create /etc/xen/hvm-wheezyD.born2b3.net.cfg
Using config file "/etc/xen/hvm-wheezyD.born2b3.net.cfg".
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

# ---
root@xen41dom0:/# tar cvpf var-log-xen-logs-AFTER-first-xm-create.tar var/log/xen/
var/log/xen/
var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log
var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log.1
var/log/xen/xend.log
var/log/xen/xend-debug.log
var/log/xen/xen-hotplug.log
# ---


What do I miss? Thank you in advance for any hints.

regards, Mark

-- ms@it-infrastrukturen.org

# ---
root@xen41dom0:/var/log/xen# xm info
host                   : xen41dom0
release                : 3.0.0-rc7
version                : #3 SMP Sat Jul 16 00:01:14 CEST 2011
machine                : x86_64
nr_cpus                : 24
nr_nodes               : 4
cores_per_socket       : 12
threads_per_core       : 1
cpu_mhz                : 2500
hw_caps                : 178bf3ff:efd3fbff:00000000:00001710:00802001:00000000:000837ff:00000000
virt_caps              : hvm
total_memory           : 32763
free_memory            : 30868
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_mem=1536M iommu=1
cc_compiler            : gcc version 4.6.1 (Debian 4.6.1-4)
cc_compile_by          : waldi
cc_compile_domain      : debian.org
cc_compile_date        : Mon Jul 18 17:41:10 UTC 2011
xend_config_format     : 4



-----Inline Attachment Follows-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 7351 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Where can I find current (and up to date) documentation for xen 4.1.1?

[Pasi Kärkkäinen]

On Wed, Aug 03, 2011 at 12:20:16AM +0200, Mark Schneider wrote:
> Hello
>

Hello,

first of all.. please don't start a new thread by replying to random email.
Please post a totally new email so you get a new thread for your issue.

> After installing xen-docs-4.1 debian package (s. below) I was expecting  
> an "up to date" documentation for xen 4.1.1.
> # ---
> ii  xen-docs-4.1                         4.1.1-1                          
>  Documentation for Xen
> # ---
>
> Two of three .pdf files (interface.pdf/user.pdf) show at the first page  
> xen 3.0 or 3.3.
> Does anything has changed for xen 4.1.1? .. or maybe the only  
> documentation source is just xen-wiki?
>
> Thank you in advance for any hints.
>

Yep, the pdf docs are out-of-date.
Most of the new stuff is on wiki pages:

http://wiki.xen.org/xenwiki/Xen4.1
http://wiki.xen.org/xenwiki/Xen4.0 (this one actually has a lot of info which also applies to 4.1)
http://wiki.xen.org/xenwiki/XenParavirtOps
http://wiki.xen.org/xenwiki/XenCommonProblems

-- Pasi

Re: xen 4.1.1 - Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

[Mark Schneider]

[-- Attachment #1.1: Type: text/plain, Size: 5550 bytes --]

Hi Boris. Thank you. It is (as below):
# ---
c_compiler            : gcc version 4.6.1 (Debian 4.6.1-4)

Regards, Mark


Am 03.08.2011 03:02, schrieb Boris Derzhavets:
> What is your  GCC version ?
>
> Boris.
>
> --- On *Tue, 8/2/11, Mark Schneider /<ms@it-infrastrukturen.org>/* wrote:
>
>
>     From: Mark Schneider <ms@it-infrastrukturen.org>
>     Subject: [Xen-devel] xen 4.1.1 - Error: Device 0 (vif) could not
>     be connected. Hotplug scripts not working.
>     To: xen-devel@lists.xensource.com
>     Date: Tuesday, August 2, 2011, 7:29 PM
>
>     Hello,
>
>     I need your kindly help. I am getting an error message when trying
>     create an HVM on xen 4.1.1 (debian wheezy with kernel 3.0.0-rc7)
>     (s. more details below and attached log files). The same config
>     works as expected on xen 4.0 (debian sqeueeze). In both cases dom0
>     runs in live mode from an USB-stick.
>
>     # ---
>     root@xen41dom0:/etc/xen# xm create
>     /etc/xen/hvm-wheezyD.born2b3.net.cfg
>     Using config file "/etc/xen/hvm-wheezyD.born2b3.net.cfg".
>     Error: Device 0 (vif) could not be connected. Hotplug scripts not
>     working.
>     # ---
>
>     Some details:
>     # ---
>     root@xen41dom0:/var/log/xen# ln -s /usr/lib/xen-4.1 /usr/lib/xen
>
>     root@xen41dom0:/var/log/xen# modprobe -l | grep xen-gnt
>     kernel/drivers/xen/xen-gntdev.ko
>     kernel/drivers/xen/xen-gntalloc.ko
>
>     xenfs on /proc/xen type xenfs (rw)
>     /dev/mapper/vg_depos-ftp on /ftp type ext4 (rw)
>     # ---
>
>     # ---
>     root@xen41dom0:/etc/xen/scripts# xm list
>     Name                                        ID   Mem VCPUs     
>     State   Time(s)
>     Domain-0                                     0  1536    24 
>        r-----    456.3
>     wheezyhvm.born2b3.net                        1  8192     1 
>        --p---      0.0
>
>     root@xen41dom0:/etc/xen/scripts# xm list
>     Name                                        ID   Mem VCPUs     
>     State   Time(s)
>     Domain-0                                     0  1536    24 
>        r-----    465.6
>     # ---
>
>     # ---
>     root@xen41dom0:/etc/xen# sed -n '/^[a-z]/p'
>     hvm-wheezyD.born2b3.net.cfg
>     kernel      = '/usr/lib64/xen-default/boot/hvmloader'
>     builder     = 'hvm'
>     device_model= '/usr/lib64/xen-4.1/bin/qemu-dm'
>     name        = 'wheezyhvm.born2b3.net'
>     acpi        = 1
>     apic        = 1
>     vif         = ['bridge=eth0']
>     disk        = [
>     'phy:/dev/vg_wheezy/wheezy,ioemu:hda,w','file:/ftp/debian-testing-amd64-DVD-1.iso,ioemu:hdc:cdrom,r']
>     vcpus       = '8'
>     memory      = '8192'
>     boot        = 'cd'
>     vnc         = 1
>     vncviewer   = 1
>     vncdisplay  = 9
>     serial      = 'pty'
>     usb         = 1
>     usbdevice   = 'tablet'
>     # ---
>
>     # ---
>     root@xen41dom0:/# tar cvpf
>     var-log-xen-logs-before-first-xm-create.tar var/log/xen/
>     var/log/xen/
>     var/log/xen/xend.log
>     var/log/xen/xend-debug.log
>     var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log
>     var/log/xen/xen-hotplug.log
>     # ---
>
>     modprobe xen-gntdev
>
>     root@xen41dom0:/etc/xen# xm create
>     /etc/xen/hvm-wheezyD.born2b3.net.cfg
>     Using config file "/etc/xen/hvm-wheezyD.born2b3.net.cfg".
>     Error: Device 0 (vif) could not be connected. Hotplug scripts not
>     working.
>
>     # ---
>     root@xen41dom0:/# tar cvpf
>     var-log-xen-logs-AFTER-first-xm-create.tar var/log/xen/
>     var/log/xen/
>     var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log
>     var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log.1
>     var/log/xen/xend.log
>     var/log/xen/xend-debug.log
>     var/log/xen/xen-hotplug.log
>     # ---
>
>
>     What do I miss? Thank you in advance for any hints.
>
>     regards, Mark
>
>     -- ms@it-infrastrukturen.org
>     </mc/compose?to=ms@it-infrastrukturen.org>
>
>     # ---
>     root@xen41dom0:/var/log/xen# xm info
>     host                   : xen41dom0
>     release                : 3.0.0-rc7
>     version                : #3 SMP Sat Jul 16 00:01:14 CEST 2011
>     machine                : x86_64
>     nr_cpus                : 24
>     nr_nodes               : 4
>     cores_per_socket       : 12
>     threads_per_core       : 1
>     cpu_mhz                : 2500
>     hw_caps                :
>     178bf3ff:efd3fbff:00000000:00001710:00802001:00000000:000837ff:00000000
>     virt_caps              : hvm
>     total_memory           : 32763
>     free_memory            : 30868
>     free_cpus              : 0
>     xen_major              : 4
>     xen_minor              : 1
>     xen_extra              : .1
>     xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p
>     hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
>     xen_scheduler          : credit
>     xen_pagesize           : 4096
>     platform_params        : virt_start=0xffff800000000000
>     xen_changeset          : unavailable
>     xen_commandline        : dom0_mem=1536M iommu=1
>     cc_compiler            : gcc version 4.6.1 (Debian 4.6.1-4)
>     cc_compile_by          : waldi
>     cc_compile_domain      : debian.org
>     cc_compile_date        : Mon Jul 18 17:41:10 UTC 2011
>     xend_config_format     : 4
>
>
>
>     -----Inline Attachment Follows-----
>
>     _______________________________________________
>     Xen-devel mailing list
>     Xen-devel@lists.xensource.com
>     </mc/compose?to=Xen-devel@lists.xensource.com>
>     http://lists.xensource.com/xen-devel
>
>
> _______________________________________________


[-- Attachment #1.2: Type: text/html, Size: 9137 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: xen 4.1.1 - Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

[Pasi Kärkkäinen]

On Wed, Aug 03, 2011 at 10:14:03AM +0200, Mark Schneider wrote:
>    Hi Boris. Thank you. It is (as below):
>    # ---
>    c_compiler            : gcc version 4.6.1 (Debian 4.6.1-4)
> 

Hey,

You're probably hitting this bug:
http://wiki.xensource.com/xenwiki/XenCommonProblems#head-775c8bcbc9f0470082f79af0c7a29a43392960bf

-- Pasi

>    Regards, Mark
> 
>    Am 03.08.2011 03:02, schrieb Boris Derzhavets:
> 
> What is your  GCC version ?
> 
> Boris.
> 
> --- On Tue, 8/2/11, Mark Schneider [1]<ms@it-infrastrukturen.org> wrote:
> 
>   From: Mark Schneider [2]<ms@it-infrastrukturen.org>
>   Subject: [Xen-devel] xen 4.1.1 - Error: Device 0 (vif) could not be connected. Hotplug scripts not
>   working.
>   To: [3]xen-devel@lists.xensource.com
>   Date: Tuesday, August 2, 2011, 7:29 PM
> 
>   Hello,
> 
>   I need your kindly help. I am getting an error message when trying create an HVM on xen 4.1.1 (debian
>   wheezy with kernel 3.0.0-rc7) (s. more details below and attached log files). The same config works as
>   expected on xen 4.0 (debian sqeueeze). In both cases dom0 runs in live mode from an USB-stick.
> 
>   # ---
>   root@xen41dom0:/etc/xen# xm create /etc/xen/hvm-wheezyD.born2b3.net.cfg
>   Using config file "/etc/xen/hvm-wheezyD.born2b3.net.cfg".
>   Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
>   # ---
> 
>   Some details:
>   # ---
>   root@xen41dom0:/var/log/xen# ln -s /usr/lib/xen-4.1 /usr/lib/xen
> 
>   root@xen41dom0:/var/log/xen# modprobe -l | grep xen-gnt
>   kernel/drivers/xen/xen-gntdev.ko
>   kernel/drivers/xen/xen-gntalloc.ko
> 
>   xenfs on /proc/xen type xenfs (rw)
>   /dev/mapper/vg_depos-ftp on /ftp type ext4 (rw)
>   # ---
> 
>   # ---
>   root@xen41dom0:/etc/xen/scripts# xm list
>   Name                                        ID   Mem VCPUs      State   Time(s)
>   Domain-0                                     0  1536    24     r-----    456.3
>   wheezyhvm.born2b3.net                        1  8192     1     --p---      0.0
> 
>   root@xen41dom0:/etc/xen/scripts# xm list
>   Name                                        ID   Mem VCPUs      State   Time(s)
>   Domain-0                                     0  1536    24     r-----    465.6
>   # ---
> 
>   # ---
>   root@xen41dom0:/etc/xen# sed -n '/^[a-z]/p' hvm-wheezyD.born2b3.net.cfg
>   kernel      = '/usr/lib64/xen-default/boot/hvmloader'
>   builder     = 'hvm'
>   device_model= '/usr/lib64/xen-4.1/bin/qemu-dm'
>   name        = 'wheezyhvm.born2b3.net'
>   acpi        = 1
>   apic        = 1
>   vif         = ['bridge=eth0']
>   disk        = [
>   'phy:/dev/vg_wheezy/wheezy,ioemu:hda,w','[4]file:/ftp/debian-testing-amd64-DVD-1.iso,ioemu:hdc:cdrom,r']
>   vcpus       = '8'
>   memory      = '8192'
>   boot        = 'cd'
>   vnc         = 1
>   vncviewer   = 1
>   vncdisplay  = 9
>   serial      = 'pty'
>   usb         = 1
>   usbdevice   = 'tablet'
>   # ---
> 
>   # ---
>   root@xen41dom0:/# tar cvpf var-log-xen-logs-before-first-xm-create.tar var/log/xen/
>   var/log/xen/
>   var/log/xen/xend.log
>   var/log/xen/xend-debug.log
>   var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log
>   var/log/xen/xen-hotplug.log
>   # ---
> 
>   modprobe xen-gntdev
> 
>   root@xen41dom0:/etc/xen# xm create /etc/xen/hvm-wheezyD.born2b3.net.cfg
>   Using config file "/etc/xen/hvm-wheezyD.born2b3.net.cfg".
>   Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
> 
>   # ---
>   root@xen41dom0:/# tar cvpf var-log-xen-logs-AFTER-first-xm-create.tar var/log/xen/
>   var/log/xen/
>   var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log
>   var/log/xen/qemu-dm-wheezyhvm.born2b3.net.log.1
>   var/log/xen/xend.log
>   var/log/xen/xend-debug.log
>   var/log/xen/xen-hotplug.log
>   # ---
> 
>   What do I miss? Thank you in advance for any hints.
> 
>   regards, Mark
> 
>   -- [5]ms@it-infrastrukturen.org
> 
>   # ---
>   root@xen41dom0:/var/log/xen# xm info
>   host                   : xen41dom0
>   release                : 3.0.0-rc7
>   version                : #3 SMP Sat Jul 16 00:01:14 CEST 2011
>   machine                : x86_64
>   nr_cpus                : 24
>   nr_nodes               : 4
>   cores_per_socket       : 12
>   threads_per_core       : 1
>   cpu_mhz                : 2500
>   hw_caps                : 178bf3ff:efd3fbff:00000000:00001710:00802001:00000000:000837ff:00000000
>   virt_caps              : hvm
>   total_memory           : 32763
>   free_memory            : 30868
>   free_cpus              : 0
>   xen_major              : 4
>   xen_minor              : 1
>   xen_extra              : .1
>   xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
>   xen_scheduler          : credit
>   xen_pagesize           : 4096
>   platform_params        : virt_start=0xffff800000000000
>   xen_changeset          : unavailable
>   xen_commandline        : dom0_mem=1536M iommu=1
>   cc_compiler            : gcc version 4.6.1 (Debian 4.6.1-4)
>   cc_compile_by          : waldi
>   cc_compile_domain      : debian.org
>   cc_compile_date        : Mon Jul 18 17:41:10 UTC 2011
>   xend_config_format     : 4
> 
>   -----Inline Attachment Follows-----
> 
>   _______________________________________________
>   Xen-devel mailing list
>   [6]Xen-devel@lists.xensource.com
>   [7]http://lists.xensource.com/xen-devel
> 
> 
>  _______________________________________________
> 
> References
> 
>    Visible links
>    1. mailto:ms@it-infrastrukturen.org
>    2. mailto:ms@it-infrastrukturen.org
>    3. mailto:xen-devel@lists.xensource.com
>    4. file://ftp/debian-testing-amd64-DVD-1.iso,ioemu:hdc:cdrom,r
>    5. file:///mc/compose?to=ms@it-infrastrukturen.org
>    6. file:///mc/compose?to=Xen-devel@lists.xensource.com
>    7. http://lists.xensource.com/xen-devel

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel

[Ian Campbell]

On Mon, 2011-08-01 at 13:58 +0100, Olaf Hering wrote:
> On Fri, Jul 29, Stefano Stabellini wrote:
> 
> > On Thu, 28 Jul 2011, Olaf Hering wrote:
> > > (this is actually a forward port of rev 1079 from 2.6.18.hg, untested because
> > > kdump just hangs before (or while) entering the crash kernel in 3.0)
> > > 
> > > After triggering a crash dump in a HVM guest, the PV backend drivers
> > > will remain in connected state. When the kdump kernel starts the PV
> > > drivers will skip such devices. As a result, no root device is found and
> > > the vmcore cant be saved.
> > > 
> > > With this change all frontend devices with state XenbusStateConnected
> > > will be reset by changing the state file to Closing/Closed/Initializing.
> > > This will trigger a disconnect in the backend drivers. Now the frontend
> > > drivers will find the backend drivers in state Initwait and can connect.
> > > 
> > > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > > 
> > > ---
> > >  drivers/xen/xenbus/xenbus_comms.c          |    4 -
> > >  drivers/xen/xenbus/xenbus_probe_frontend.c |   97 +++++++++++++++++++++++++++++
> > >  2 files changed, 100 insertions(+), 1 deletion(-)
> > > 
> > > Index: linux-3.0/drivers/xen/xenbus/xenbus_comms.c
> > > ===================================================================
> > > --- linux-3.0.orig/drivers/xen/xenbus/xenbus_comms.c
> > > +++ linux-3.0/drivers/xen/xenbus/xenbus_comms.c
> > > @@ -212,7 +212,9 @@ int xb_init_comms(void)
> > >  		printk(KERN_WARNING "XENBUS response ring is not quiescent "
> > >  		       "(%08x:%08x): fixing up\n",
> > >  		       intf->rsp_cons, intf->rsp_prod);
> > > -		intf->rsp_cons = intf->rsp_prod;
> > > +		/* breaks kdump */
> > > +		if (!reset_devices)
> > > +			intf->rsp_cons = intf->rsp_prod;
> > >  	}
> > 
> > Where is reset_devices coming from?
> > I hope is set only on a kexec reboot.
> 
> This is for a kdump boot, its added as additional kernel cmdline option
> for the kdump kernel.

It is commonly used with kdump but is it kdump specific?

I suppose this usage is not that far from the stated semantics of the
option ("Force drivers to reset the underlying device during
initialization" from Documentation/kernel-parameters.txt). But is there
any reason not to just always reset the rings on initialisation? There
can't be any real outstanding requests at this point and I think we
determined that xenstored should (and does) cope gracefully with this
(since hvmloader also does it).

> > Considering that all the other patches in this series follow the
> > opposite strategy, that is closing stuff on shutdown, why are you trying
> > to close xenbus connections on boot here?
> > At this point I would rather be coherent and simply switch to
> > XenbusStateClosing or XenbusStateClosed in the shutdown path if
> > kexec_is_loaded.

I'd prefer to be coherent too but in the other direction -- i.e. as much
of the work as possible should be pushed into the target kernel not done
in the source kernel. By definition you can't really rely on the source
kernel to be a) working at all (in the crash dump case) and b) not have
bugs on the shutdown path (at least the target kernel can have the fixes
applied before attempting to kexec etc).

> 
> To allow the kdump kernel to store the /proc/vmcore file somewhere, it
> has to get either storage or network access.  But the kdump kernel finds
> all devices in the Connected state, because the to-be-debugged kernel
> just crashed. So it has to reset the connection to the backend.
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel