LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Christopher S. Aker" <caker@theshore.net>
Cc: virtualization@lists.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Xen-devel <xen-devel@lists.xensource.com>
Subject: Re: Xen paravirt frontend block hang
Date: Thu, 28 Feb 2008 12:00:47 -0800	[thread overview]
Message-ID: <47C712EF.1060703@goop.org> (raw)
In-Reply-To: <4772AC8E.7010007@theshore.net>

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

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@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/virtualization


[-- Attachment #2: xen-indirect-iret.patch --]
[-- Type: text/x-patch, Size: 2429 bytes --]

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@xensource.com>

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

       reply	other threads:[~2008-02-28 20:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4772AC8E.7010007@theshore.net>
2008-02-28 20:00 ` Jeremy Fitzhardinge [this message]
2008-03-02  0:43   ` Christopher S. Aker
2008-03-02 15:35     ` Jeremy Fitzhardinge
2008-03-02 16:03       ` Christopher S. Aker
2008-03-18 16:01         ` [Xen-devel] " Jeremy Fitzhardinge
2008-03-25  1:37           ` Christopher S. Aker
     [not found] ` <47758352.5040504@goop.org>
     [not found]   ` <479E71B7.7060207@theshore.net>
     [not found]     ` <479E75E3.6030601@goop.org>
     [not found]       ` <479E7BA4.5050306@theshore.net>
     [not found]         ` <519a8b110802060437k70c099b7y7faefe63dd82039@mail.gmail.com>
     [not found]           ` <47AA845E.8020708@goop.org>
     [not found]             ` <519a8b110802070612j2a1717f3s6aa25eeea8b7d18a@mail.gmail.com>
2008-02-28 20:03               ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47C712EF.1060703@goop.org \
    --to=jeremy@goop.org \
    --cc=caker@theshore.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xen-devel@lists.xensource.com \
    --subject='Re: Xen paravirt frontend block hang' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).