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

Re: [Xen-devel] [PATCH 2/5] xen/x86-64: clean up warnings aboutIST-using

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/x86-64: clean up warnings aboutIST-using traps
From: Ingo Molnar <mingo@xxxxxxx>
Date: Fri, 8 May 2009 10:58:05 +0200
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
Delivery-date: Fri, 08 May 2009 01:59:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A03F947.76EA.0078.0@xxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4A032EE0.9030607@xxxxxxxx> <4A03F947.76EA.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
* Jan Beulich <jbeulich@xxxxxxxxxx> wrote:

> >>> Jeremy Fitzhardinge <jeremy@xxxxxxxx> 07.05.09 20:56 >>>
> >Ignore known IST-using traps.  Aside from the debugger traps, they're
> >low-level faults which Xen will handle for us, so the kernel needn't
> >worry about them.  Keep warning in case unknown trap starts using IST.
> >
> >Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
> >---
> > arch/x86/xen/enlighten.c |   22 ++++++++++++++++++++--
> > 1 files changed, 20 insertions(+), 2 deletions(-)
> >
> >diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >index cb49f57..88f3aa4 100644
> >--- a/arch/x86/xen/enlighten.c
> >+++ b/arch/x86/xen/enlighten.c
> >@@ -439,12 +439,30 @@ static int cvt_gate_to_trap(int vector, const 
> >gate_desc *val,
> > 
> >     addr = gate_offset(*val);
> > #ifdef CONFIG_X86_64
> >+    /*
> >+     * Look for known traps using IST, and substitute them
> >+     * appropriately.  The debugger ones are the only ones we care
> >+     * about.  Xen will handle faults like double_fault and
> >+     * machine_check, so we should never see them.  Warn if
> >+     * there's an unexpected IST-using fault handler.
> >+     */
> >     if (addr == (unsigned long)debug)
> >             addr = (unsigned long)xen_debug;
> >     else if (addr == (unsigned long)int3)
> >             addr = (unsigned long)xen_int3;
> >-    else
> >-            WARN_ON(val->ist != 0);
> >+    else if (addr == (unsigned long)double_fault ||
> >+             addr == (unsigned long)stack_segment) {
> 
> I don't think you want to exclude handling stack faults: Ordinary 
> memory references using rsp or rbp as the base register will cause 
> these instead of general protection faults when the resulting 
> effective address is non- canonical.

Yes. Also, patches 1-2-3 really just do the same thing, one fixes 
the other one. Would be nice to have a single patch for that whole 
ugly topic of 64-bit Xen not handling ISTs properly.

If this was a CPU we'd say "sorry, dont run Linux on it then" ...

I've applied the reservation fix to x86/urgent, and the #5 patch to 
x86/xen (it's more of a cleanup, not a fix for .30, right?).

        Ingo

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel