From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xen.org
Subject: Re: [PATCH] [RFC 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 12:16:27 +0000 [thread overview]
Message-ID: <50A23A1B.6030404@citrix.com> (raw)
In-Reply-To: <20121113120555.GC44675@ocelot.phlegethon.org>
On 13/11/12 12:05, Tim Deegan wrote:
> At 11:47 +0000 on 13 Nov (1352807234), Tim Deegan wrote:
>> At 11:38 +0000 on 13 Nov (1352806689), Jan Beulich wrote:
>>>> diff -r 62885b3c34c8 -r ea756059a8da 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. */
>>> In any case - why can't you call do_nmi() directly from here?
>> ... this is my doing. There used to be a call to do_nmi() here, but
>> do_nmi() doesn't block NMIs, so you can't just call it here in case you
>> get _another_ NMI while you're in the NMI handler.
> Oh wait, I see -- you're saying that this (20059:76a65bf2aa4d) is wrong
> because NMIs are indeed blocked, and have been since the VMEXIT.
>
> In that case, I agree that we should just run the NMI handler, but first
> I would really like to know what _unblocks_ NMIs in this case. Any of
> the things I can think of (the next vmenter, the next iret, ??) will
> need some handling to make sure they actually happen before, say, we
> take this CPU into the idle loop...
>
> Tim.
The first experiment was to have self_nmi() wait until the NMI count for
the current processor changed. This prevented the thousands of bounces
in and out of non-root mode, but the enter delays fairly consistently in
the millions of TSC ticks (a few milliseconds on the test box), which is
a noticeable chunk of time.
~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
--
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com
next prev parent reply other threads:[~2012-11-13 12:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-13 11:23 [PATCH] [RFC PATCH] xen: vmx: Use an INT 2 call to process real NMI's instead of self_nmi() in VMEXIT handler Malcolm Crossley
2012-11-13 11:38 ` Jan Beulich
2012-11-13 11:47 ` Tim Deegan
2012-11-13 12:05 ` Tim Deegan
2012-11-13 12:16 ` Andrew Cooper [this message]
2012-11-13 12:17 ` Ian Campbell
2012-11-13 12:39 ` Tim Deegan
2012-11-13 14:21 ` Jan Beulich
2012-11-13 14:43 ` Tim Deegan
2012-11-13 14:56 ` Jan Beulich
2012-11-13 15:21 ` Tim Deegan
2012-11-13 15:32 ` Jan Beulich
2012-11-13 15:14 ` Andrew Cooper
2012-11-13 14:47 ` Jan Beulich
2012-11-13 11:48 ` Andrew Cooper
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=50A23A1B.6030404@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=xen-devel@lists.xen.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.