[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:http://lists.xensource.com/archives/html/xen-devel/2007-11/msg00777.htmlI 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 doneAfter 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 */ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |