From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir@xen.org>
Subject: Re: [PATCH] xen: vmx: Use an INT 2 call to process real
 NMI's instead of self_nmi() in VMEXIT handler
Date: Tue, 13 Nov 2012 14:28:48 +0000
Message-ID: <CCC809A0.520FE%keir@xen.org>
References: <20121113133953.GF44675@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20121113133953.GF44675@ocelot.phlegethon.org>
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: Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "eddie.dong@intel.com" <eddie.dong@intel.com>, "JBeulich@suse.com" <JBeulich@suse.com>, "Nakajima,
	Jun" <jun.nakajima@intel.com>
List-Id: xen-devel@lists.xenproject.org

On 13/11/2012 13:39, "Tim Deegan" <tim@xen.org> wrote:

>>> diff -r 62885b3c34c8 -r e1fbee58b25c xen/arch/x86/hvm/vmx/vmx.c
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -2442,7 +2442,7 @@ void vmx_vmexit_handler(struct cpu_user_
>>>                   (X86_EVENTTYPE_NMI << 8) )
>>>                  goto exit_and_crash;
>>>              HVMTRACE_0D(NMI);
>>> -            self_nmi(); /* Real NMI, vector 2: normal processing. */
>>> +            asm("int $2"); /* Real NMI, vector 2: normal processing. */
>> 
>>                asm volatile("...")
>> 
>> I think? Otherwise this could potentially get hoisted up
> 
> Good catch.  Hoisted would be fine, but it could also be entirely
> discarded. :)

Parameter-less asm blocks are a special case that will never be considered
side-effect free I believe. Still 'asm volatile' would be our stylistic
choice in this case anyway.

And with that:
Acked-by: Keir Fraser <keir@xen.org>