Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 00/11] [v2] misc changes for kexec in pv-on-hvm guests
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 01/11] kexec: add kexec_is_loaded function
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);
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 02/11] xen: remove BUG_ON from xen_teardown_timer
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);
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 03/11] xen: use static initializers in xen-balloon.c
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;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 04/11] xen/hvm kexec: unregister timer interrupt during reboot
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 05/11] xen/hvm kexec: unregister debugirq during reboot
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)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 06/11] xen/hvm kexec: unregister shutdown+sysrq watches during reboot
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;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 07/11] xen/hvm kexec: unregister memory/target watch in xen-balloon.c
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;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 08/11] xen/hvm kexec: unregister the watch of the "backend" node during reboot
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;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 09/11] xen/hvm kexec: unregister the watch of the "device" node during reboot
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;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 10/11] xen kexec: reset device state to Initializing during reboot
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);
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Olaf Hering
2011-Jul-28 13:23 UTC
[Xen-devel] [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel
(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);
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2011-Jul-28 13:43 UTC
Re: [Xen-devel] [PATCH 00/11] [v2] misc changes for kexec in pv-on-hvm guests
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2011-Jul-29 14:45 UTC
Re: [Xen-devel] [PATCH 01/11] kexec: add kexec_is_loaded function
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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2011-Jul-29 14:47 UTC
Re: [Xen-devel] [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jul-29 17:34 UTC
Re: [Xen-devel] [PATCH 01/11] kexec: add kexec_is_loaded function
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 asNot 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.hAnd 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jul-29 17:35 UTC
Re: [Xen-devel] [PATCH 00/11] [v2] misc changes for kexec in pv-on-hvm guests
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jul-29 17:45 UTC
Re: [Xen-devel] [PATCH 05/11] xen/hvm kexec: unregister debugirq during reboot
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() functionIs 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Olaf Hering
2011-Aug-01 12:58 UTC
Re: [Xen-devel] [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Olaf Hering
2011-Aug-01 12:59 UTC
Re: [Xen-devel] [PATCH 01/11] kexec: add kexec_is_loaded function
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Olaf Hering
2011-Aug-01 13:00 UTC
Re: [Xen-devel] [PATCH 00/11] [v2] misc changes for kexec in pv-on-hvm guests
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2011-Aug-02 21:04 UTC
Re: [Xen-devel] [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Schneider
2011-Aug-02 22:20 UTC
[Xen-devel] Where can I find current (and up to date) documentation for xen 4.1.1?
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-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Schneider
2011-Aug-02 22:42 UTC
[Xen-devel] xen 4.1.1 - errors in xend-debug.log: cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Schneider
2011-Aug-02 22:48 UTC
[Xen-devel] [2011-08-02 20:54:36 2721] WARNING (XendAPI:708) API call: VBD.set_device not found
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-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Mark Schneider
2011-Aug-02 23:29 UTC
[Xen-devel] xen 4.1.1 - Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2011-Aug-03 01:02 UTC
Re: [Xen-devel] xen 4.1.1 - Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2011-Aug-03 04:55 UTC
Re: [Xen-devel] Where can I find current (and up to date) documentation for xen 4.1.1?
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Schneider
2011-Aug-03 08:14 UTC
Re: [Xen-devel] xen 4.1.1 - Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
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 > > > ______________________________________________________________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2011-Aug-03 16:43 UTC
Re: [Xen-devel] xen 4.1.1 - Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Aug-09 09:07 UTC
Re: [Xen-devel] [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel