xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT handler
Date: Thu, 28 Feb 2013 16:01:09 +0000	[thread overview]
Message-ID: <CD552FC5.5D0ED%keir@xen.org> (raw)
In-Reply-To: <512F88B002000078000C21AA@nat28.tlf.novell.com>

On 28/02/2013 15:41, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 28.02.13 at 15:42, "Jan Beulich" <JBeulich@suse.com> wrote:
>> ... this must not be done when on the NMI stack (i.e. when the
>> NMI was raised while in hypervisor context). Checking for this
>> here would be strait forward, but I was really considering to do
>> all of this in the assembly exit path, and I was still undecided
>> whether we shouldn't follow Linux in skipping softirq processing
>> (and hence scheduling) on the way out from an NMI (I don't
>> think we'd need to do the same for MCE).
> 
> Like this:
> 
> x86: skip processing events on the NMI exit path
> 
> Otherwise, we may end up in the scheduler, keeping NMIs masked for a
> possibly unbounded time (until whenever the next IRET gets executed).

Is this alternative that we might not process events for an unbounded time?
No, I guess not -- either we would interrupt the notifying IPI and we will
be IRETing into that IPI's handler, or the notifying IPI is delayed until
the NMI handler's IRET.

What about if the NMI handler itself raises an event (eg softirq)? Perhaps
there are no very essential ones of those?

> Of course it's open for discussion whether to always use the strait
> exit path from handle_ist_exception.

s/strait/straight (and below in the code comment that you add).

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -171,7 +171,7 @@ compat_bad_hypercall:
>          jmp  compat_test_all_events
>  
>  /* %rbx: struct vcpu, interrupts disabled */
> -compat_restore_all_guest:
> +ENTRY(compat_restore_all_guest)
>          ASSERT_INTERRUPTS_DISABLED
>          RESTORE_ALL adj=8 compat=1
>  .Lft0:  iretq
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -635,6 +635,9 @@ ENTRY(early_page_fault)
>          jmp   restore_all_xen
>          .popsection
>  
> +ENTRY(nmi)
> +        pushq $0
> +        movl  $TRAP_nmi,4(%rsp)
>  handle_ist_exception:
>          SAVE_ALL
>          testb $3,UREGS_cs(%rsp)
> @@ -649,12 +652,17 @@ handle_ist_exception:
>          movzbl UREGS_entry_vector(%rsp),%eax
>          leaq  exception_table(%rip),%rdx
>          callq *(%rdx,%rax,8)
> -        jmp   ret_from_intr
> +        cmpb  $TRAP_nmi,UREGS_entry_vector(%rsp)
> +        jne   ret_from_intr
>  
> -ENTRY(nmi)
> -        pushq $0
> -        movl  $TRAP_nmi,4(%rsp)
> -        jmp   handle_ist_exception
> +        /* We want to get strait to the IRET in the NMI exit path. */
> +        testb $3,UREGS_cs(%rsp)
> +        GET_CURRENT(%rbx)
> +        jz    restore_all_xen
> +        movq  VCPU_domain(%rbx),%rax
> +        testb $1,DOMAIN_is_32bit_pv(%rax)
> +        jz    restore_all_guest
> +        jmp   compat_restore_all_guest
>  
>  ENTRY(nmi_crash)
>          pushq $0
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

  parent reply	other threads:[~2013-02-28 16:01 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-22 15:00 [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT handler Andrew Cooper
2012-11-22 15:15 ` Jan Beulich
2012-11-22 15:16   ` Andrew Cooper
2012-11-22 15:21     ` Jan Beulich
2012-11-22 15:37       ` Andrew Cooper
2012-11-22 15:55         ` Jan Beulich
2012-11-22 16:05           ` Andrew Cooper
2012-11-22 16:12             ` Jan Beulich
2012-11-22 16:31               ` Andrew Cooper
2013-02-28  9:58             ` Jan Beulich
2013-02-28 12:32               ` Andrew Cooper
2013-02-28 13:00               ` Tim Deegan
2013-02-28 13:12                 ` Andrew Cooper
2013-02-28 13:39                 ` Jan Beulich
2013-02-28 14:25                   ` Tim Deegan
2013-02-28 14:42                     ` Jan Beulich
2013-02-28 14:45                       ` Andrew Cooper
2013-02-28 14:49                       ` Tim Deegan
2013-02-28 15:01                         ` Jan Beulich
2013-02-28 15:41                       ` Jan Beulich
2013-02-28 15:52                         ` Andrew Cooper
2013-02-28 15:55                         ` Tim Deegan
2013-02-28 16:12                           ` Jan Beulich
2013-02-28 16:01                         ` Keir Fraser [this message]
2013-02-28 16:17                           ` Jan Beulich
2013-02-28 19:02                             ` Keir Fraser
2013-03-01 10:49                               ` [PATCH v2 0/2] x86: defer processing events on the NMI exit path Jan Beulich
2013-03-01 10:56                                 ` [PATCH v2 1/2] " Jan Beulich
2013-03-01 11:37                                   ` Andrew Cooper
2013-03-01 11:53                                     ` Jan Beulich
2013-03-01 15:56                                       ` Keir Fraser
2013-03-01 16:01                                         ` Andrew Cooper
2013-03-01 16:08                                           ` Jan Beulich
2013-03-01 10:57                                 ` [PATCH v2 2/2] x86: don't rely on __softirq_pending to be the first field in irq_cpustat_t Jan Beulich
2013-03-01 15:55                                 ` [PATCH v2 0/2] x86: defer processing events on the NMI exit path Keir Fraser
2013-02-28 13:42                 ` [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT handler Jan Beulich
2013-02-28 14:04                   ` Tim Deegan
2013-02-28 14:51                 ` Konrad Rzeszutek Wilk
2012-11-22 15:22     ` Mats Petersson
2012-11-22 16:00       ` Jan Beulich
2012-11-22 17:34 ` Tim Deegan
2012-11-26 11:50   ` George Dunlap

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=CD552FC5.5D0ED%keir@xen.org \
    --to=keir@xen.org \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=malcolm.crossley@citrix.com \
    --cc=tim@xen.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).