[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: Xen paravirt frontend block hang

Christopher S. Aker wrote:
Sorry for the noise if this isn't the appropriate venue for this. I posted this last month to xen-devel:


I can reliably cause a paravirt_ops Xen guest to hang during intensive IO. My current recipe is an untar/tar loop, without compression, of a kernel tree. For example:

wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.bz2
bzip2 -d linux-2.6.23.tar.bz2

while true;
  echo `date`
  tar xf linux-2.6.23.tar
  tar cf linux-2.6.23.tar linux-2.6.23

After a few loops, anything that touches the xvd device that hung will get stuck in D state.

I've been running this all night without seeing any problem. I'm using current x86.git#testing with a few local patches, but nothing especially relevent-looking.

Could you try the attached patch to see if it makes any difference?


This happens on both a 2.6.16 and 2.6.18 dom0 (3.1.2 tools). Paravirt guests I've tried that exhibit the problem:,, and 2.6.24-rc6. It does *not* occur using the Xensource 2.6.18 domU tree from 3.1.2. In all cases, the host continues to run fine, nothing out of the ordinary is logged on the dom0 side, xenstore reports the status of the devices is fine.

Can anyone reproduce this problem, or let me know what else I can provide to help track this down?

Virtualization mailing list

Subject: xen: use iret instruction all the time

Change iret implementation to not be dependent on direct-access vcpu

Signed-off-by: Jeremy Fitzhardinge <jeremy@xxxxxxxxxxxxx>

 arch/x86/xen/enlighten.c |    3 +--
 arch/x86/xen/xen-asm.S   |   11 +++--------
 arch/x86/xen/xen-ops.h   |    2 +-
 3 files changed, 5 insertions(+), 11 deletions(-)

--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -860,7 +860,6 @@ void __init xen_setup_vcpu_info_placemen
                pv_irq_ops.irq_disable = xen_irq_disable_direct;
                pv_irq_ops.irq_enable = xen_irq_enable_direct;
                pv_mmu_ops.read_cr2 = xen_read_cr2_direct;
-               pv_cpu_ops.iret = xen_iret_direct;
@@ -964,7 +963,7 @@ static const struct pv_cpu_ops xen_cpu_o
        .read_tsc = native_read_tsc,
        .read_pmc = native_read_pmc,
-       .iret = (void *)&hypercall_page[__HYPERVISOR_iret],
+       .iret = xen_iret,
        .irq_enable_syscall_ret = NULL,  /* never called */
        .load_tr_desc = paravirt_nop,
--- a/arch/x86/xen/xen-asm.S
+++ b/arch/x86/xen/xen-asm.S
@@ -130,13 +130,8 @@ ENDPATCH(xen_restore_fl_direct)
        current stack state in whatever form its in, we keep things
        simple by only using a single register which is pushed/popped
        on the stack.
-       Non-direct iret could be done in the same way, but it would
-       require an annoying amount of code duplication.  We'll assume
-       that direct mode will be the common case once the hypervisor
-       support becomes commonplace.
        /* test eflags for special cases */
        testl $(X86_EFLAGS_VM | XEN_EFLAGS_NMI), 8(%esp)
        jnz hyper_iret
@@ -150,9 +145,9 @@ ENTRY(xen_iret_direct)
        movl TI_cpu(%eax),%eax
        movl __per_cpu_offset(,%eax,4),%eax
-       lea per_cpu__xen_vcpu_info(%eax),%eax
+       mov per_cpu__xen_vcpu(%eax),%eax
-       movl $per_cpu__xen_vcpu_info, %eax
+       movl per_cpu__xen_vcpu, %eax
        /* check IF state we're restoring */
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -63,5 +63,5 @@ DECL_ASM(unsigned long, xen_save_fl_dire
 DECL_ASM(unsigned long, xen_save_fl_direct, void);
 DECL_ASM(void, xen_restore_fl_direct, unsigned long);
-void xen_iret_direct(void);
+void xen_iret(void);
 #endif /* XEN_OPS_H */
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.