Re: Xen paravirt frontend block hang

From: Jeremy Fitzhardinge
Date: Thu Feb 28 2008 - 15:04:59 EST

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:

http://lists.xensource.com/archives/html/xen-devel/2007-11/msg00777.html

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
done

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?

J


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: 2.6.23.8, 2.6.23.12, 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?

Thanks,
-Chris
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Subject: xen: use iret instruction all the time

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

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.
*/
-ENTRY(xen_iret_direct)
+ENTRY(xen_iret)
/* 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)
GET_THREAD_INFO(%eax)
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
#else
- movl $per_cpu__xen_vcpu_info, %eax
+ movl per_cpu__xen_vcpu, %eax
#endif

/* 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 */