From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: Regression since Linux Kernel 3.12 due to 64bit
 pvguest NMIs
Date: Mon, 12 May 2014 10:21:45 -0400
Message-ID: <20140512142144.GC2837@phenom.dumpdata.com>
References: <CAB4HUd1zE6gedePUpKdNqjiMu4m-gPVU0s1=TkVVQ2HCNUj75A@mail.gmail.com>
	<20140509200208.GA11650@phenom.dumpdata.com>
	<CAB4HUd2JXwytktjpU0upY2KDTTGJfdqibtaOkh34hQ-zK2BK9Q@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <CAB4HUd2JXwytktjpU0upY2KDTTGJfdqibtaOkh34hQ-zK2BK9Q@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Sebastian Faerber <faerber@gmail.com>
Cc: xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On Fri, May 09, 2014 at 10:28:29PM +0200, Sebastian Faerber wrote:
> >
> > Isn't it Xen 3.x based? The Linux pvops kernels I thought only
> > were 4.0 and further compatible?
> 
> Yes, it's Xen 3.x based but i can boot pvops kernels up to 3.11.
> 
> > But anyhow, I presume the:
> >
> > ffffffff810041fd
> >
> > maps to the 'ud2' instruction in 'xen_enable_nmi' ?
> 
> Correct.
> 
> > If you take the 'BUG()' out does it continue running?
> 
> You're right - it works
> 
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -559,8 +559,7 @@ void xen_enable_syscall(void)
>  void __cpuinit xen_enable_nmi(void)
>  {
>  #ifdef CONFIG_X86_64
> -       if (register_callback(CALLBACKTYPE_nmi, nmi))
> -               BUG();
> +       register_callback(CALLBACKTYPE_nmi, nmi);
>  #endif
>  }
>  void __init xen_arch_setup(void)
> 
> 
> Thanks Konrad!
> Would it be possible to guard the NMI Feature so older Xen Versions don't get
> confused and run into this BUG()?

Could you patch your kernel with this patch to double check that it is OK?

Is it OK for me to put 'Reported-and-Tested-by: Sebastian Faerber <email>'
on it?

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 201d09a..c19ae00 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -746,11 +746,14 @@ static int cvt_gate_to_trap(int vector, const gate_desc *val,
 		 */
 		;
 #endif
-	} else if (addr == (unsigned long)nmi)
+	} else if (addr == (unsigned long)nmi) {
 		/*
-		 * Use the native version as well.
+		 * Use the native version as well, but for RHEL5
+		 * hypervisors it is not implemented.
 		 */
-		;
+		if (!xen_running_on_version_or_later(4,0))
+			return 0;
+	}
 	else {
 		/* Some other trap using IST? */
 		if (WARN_ON(val->ist != 0))
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 0982233..aa3fd34 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -576,6 +576,8 @@ void xen_enable_syscall(void)
 }
 void xen_enable_nmi(void)
 {
+	if (!xen_running_on_version_or_later(4,0))
+		return;
 #ifdef CONFIG_X86_64
 	if (register_callback(CALLBACKTYPE_nmi, (char *)nmi))
 		BUG();


> 
> Regards,
> Sebastian