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/
Home Products Support Community News


RE: [Xen-devel] [SVM][PATCH] fix NMI vmexit handling

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [SVM][PATCH] fix NMI vmexit handling
From: "Woller, Thomas" <thomas.woller@xxxxxxx>
Date: Thu, 27 Jul 2006 14:32:36 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 27 Jul 2006 12:45:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <83653e4cfc7b495bc5626772f96a620a@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcawnECXWVVHbt37S06M3HC4X8dwAgAMm6tg
Thread-topic: [Xen-devel] [SVM][PATCH] fix NMI vmexit handling
> How does moving the STGI fix this double-nmi problem? The 
> reference manual says that external interrupts are 'held 
> pending' until delivery is enabled by the VMM. I can't see 
> that do_nmi() does anything that would cause that pending 
> status to be reset (local APIC isn't EOI'ed, or anything like 
> that) and so I would expect that you would still get an NMI 
> when STGI is executed, and all you've done is switch the 
> order (the explicit call to do_nmi() happens before the 
> STGI_triggered one). 
> Am I wrong?
No, you are not wrong. Attached patch removes the do_nmi() from the
vmexit handler to eliminate the second NMI handling.

Our xenoprofile solution for SVM guests currently uses a method which
sets a flag in the NMI vmexit handler, prior to the stgi(), indicating
that this particular vmexit is an NMI.  Then this flag is reset during
the nmi processing via an HVM callback function from the op_model_athon
code.  In this way, we eliminate any duplication of profile record
creation on subsequent NMIs prior to the next vmrun.  And it's easier to
handle this new functionality in the exit handler, hence the STGI

We'll post an experimental patch with the xenoprofile mods, and
appreciate your input when it's posted. 

Waiting to push this particular patch sounds like the best thing to do
now at this point, and then seeing them together which should make more

> Another thing: the code you have under case VMEXIT_INTR, 
> which raises schedule softirq, seems pointless. All interrupt 
> work will happen in proper interrupt context triggered on 
> STGI. Should the code under VMEXIT_INTR simply be removed?
Yes, the code should be removed. we'll test with this code removed, and
initiate separate patch with just this code removed.  Thanks for
catching this one also.

Attachment: svm_stgi_nmi2.patch
Description: svm_stgi_nmi2.patch

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>