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 */
next parent 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).