[v4,2/4] x86: track when in NMI context
diff mbox series

Message ID 20200226121921.28627-3-roger.pau@citrix.com
State New, archived
Headers show
Series
  • x86/smp: fix send_IPI_mask usage of scratch_cpumask
Related show

Commit Message

Roger Pau Monné Feb. 26, 2020, 12:19 p.m. UTC
Add helpers to track when running in NMI handler context. This is
modeled after the in_irq helpers.

The SDM states that no NMI can be delivered while handling a NMI
until the processor has executed an iret instruction. It's possible
however that another fault is received while handling the NMI (a #MC
for example), and thus the iret from that fault would allow further
NMIs to be injected while still processing the previous one, and
hence an integer is needed in order to keep track of in service NMIs.
The added macros only track when the execution context is in the NMI
handler, but that doesn't mean NMIs are blocked for the reasons listed
above.

Note that there are no users of in_nmi_handler() introduced by the
change, further users will be added by followup changes.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v3:
 - Rename to in_nmi_context.
 - Drop parentheses around cpu in nmi_count.

Changes since v2:
 - Use an integer instead of a boolean to keep track of in service
   #NMIs.
 - Move nmi_count into x86 specific header.
 - Drop leading underscores from __nmi_count field.
---
 xen/arch/x86/traps.c          | 6 ++++++
 xen/include/asm-x86/hardirq.h | 6 ++++++
 2 files changed, 12 insertions(+)

Comments

Jan Beulich Feb. 26, 2020, 1:02 p.m. UTC | #1
On 26.02.2020 13:19, Roger Pau Monne wrote:
> Add helpers to track when running in NMI handler context. This is
> modeled after the in_irq helpers.
> 
> The SDM states that no NMI can be delivered while handling a NMI
> until the processor has executed an iret instruction. It's possible
> however that another fault is received while handling the NMI (a #MC
> for example), and thus the iret from that fault would allow further
> NMIs to be injected while still processing the previous one, and
> hence an integer is needed in order to keep track of in service NMIs.
> The added macros only track when the execution context is in the NMI
> handler, but that doesn't mean NMIs are blocked for the reasons listed
> above.
> 
> Note that there are no users of in_nmi_handler() introduced by the
> change, further users will be added by followup changes.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

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

Patch
diff mbox series

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 3dbc66bb64..f4f2c13ae9 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1692,9 +1692,13 @@  void do_nmi(const struct cpu_user_regs *regs)
     bool handle_unknown = false;
 
     this_cpu(nmi_count)++;
+    nmi_enter();
 
     if ( nmi_callback(regs, cpu) )
+    {
+        nmi_exit();
         return;
+    }
 
     /*
      * Accessing port 0x61 may trap to SMM which has been actually
@@ -1720,6 +1724,8 @@  void do_nmi(const struct cpu_user_regs *regs)
         if ( !(reason & 0xc0) && handle_unknown )
             unknown_nmi_error(regs, reason);
     }
+
+    nmi_exit();
 }
 
 nmi_callback_t *set_nmi_callback(nmi_callback_t *callback)
diff --git a/xen/include/asm-x86/hardirq.h b/xen/include/asm-x86/hardirq.h
index 802f91cfdf..069e48fce9 100644
--- a/xen/include/asm-x86/hardirq.h
+++ b/xen/include/asm-x86/hardirq.h
@@ -7,6 +7,7 @@ 
 typedef struct {
 	unsigned int __softirq_pending;
 	unsigned int __local_irq_count;
+	unsigned int nmi_count;
 	bool_t __mwait_wakeup;
 } __cacheline_aligned irq_cpustat_t;
 
@@ -17,6 +18,11 @@  typedef struct {
 #define irq_enter()	(local_irq_count(smp_processor_id())++)
 #define irq_exit()	(local_irq_count(smp_processor_id())--)
 
+#define nmi_count(cpu)		__IRQ_STAT(cpu, nmi_count)
+#define in_nmi_handler()	(nmi_count(smp_processor_id()) != 0)
+#define nmi_enter()		(nmi_count(smp_processor_id())++)
+#define nmi_exit()		(nmi_count(smp_processor_id())--)
+
 void ack_bad_irq(unsigned int irq);
 
 extern void apic_intr_init(void);