WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Christopher S. Aker" <caker@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: Xen paravirt frontend block hang
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 28 Feb 2008 12:00:47 -0800
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 28 Feb 2008 12:05:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4772AC8E.7010007@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4772AC8E.7010007@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.9 (X11/20071115)
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 */
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>