<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/x86/kernel/nmi.c, branch linux-5.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-03-16T10:02:41Z</updated>
<entry>
<title>x86/nmi: Remove the 'strange power saving mode' hint from unknown NMI handler</title>
<updated>2022-03-16T10:02:41Z</updated>
<author>
<name>Jiri Kosina</name>
</author>
<published>2022-03-14T08:25:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d4c9df20a37d128f6acb3c6286db7e694554a51b'/>
<id>urn:sha1:d4c9df20a37d128f6acb3c6286db7e694554a51b</id>
<content type='text'>
The

  Do you have a strange power saving mode enabled?

hint when unknown NMI happens dates back to i386 stone age, and isn't
currently really helpful.

Unknown NMIs are coming for many different reasons (broken firmware,
faulty hardware, ...) and rarely have anything to do with 'strange power
saving mode' (whatever that even is).

Just remove it as it's largerly misleading.

Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Acked-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2203140924120.24795@cbobk.fhfr.pm
</content>
</entry>
<entry>
<title>x86/sev-es: Rename sev-es.{ch} to sev.{ch}</title>
<updated>2021-05-10T05:40:27Z</updated>
<author>
<name>Brijesh Singh</name>
</author>
<published>2021-04-27T11:16:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e759959fe3b8313c81d6200be44cb8a644d845ea'/>
<id>urn:sha1:e759959fe3b8313c81d6200be44cb8a644d845ea</id>
<content type='text'>
SEV-SNP builds upon the SEV-ES functionality while adding new hardware
protection. Version 2 of the GHCB specification adds new NAE events that
are SEV-SNP specific. Rename the sev-es.{ch} to sev.{ch} so that all
SEV* functionality can be consolidated in one place.

Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Acked-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Link: https://lkml.kernel.org/r/20210427111636.1207-2-brijesh.singh@amd.com
</content>
</entry>
<entry>
<title>KVM/VMX: Invoke NMI non-IST entry instead of IST entry</title>
<updated>2021-05-05T20:54:10Z</updated>
<author>
<name>Lai Jiangshan</name>
</author>
<published>2021-05-04T19:50:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a217a6593cec8b315d4c2f344bae33660b39b703'/>
<id>urn:sha1:a217a6593cec8b315d4c2f344bae33660b39b703</id>
<content type='text'>
In VMX, the host NMI handler needs to be invoked after NMI VM-Exit.
Before commit 1a5488ef0dcf6 ("KVM: VMX: Invoke NMI handler via indirect
call instead of INTn"), this was done by INTn ("int $2"). But INTn
microcode is relatively expensive, so the commit reworked NMI VM-Exit
handling to invoke the kernel handler by function call.

But this missed a detail. The NMI entry point for direct invocation is
fetched from the IDT table and called on the kernel stack.  But on 64-bit
the NMI entry installed in the IDT expects to be invoked on the IST stack.
It relies on the "NMI executing" variable on the IST stack to work
correctly, which is at a fixed position in the IST stack.  When the entry
point is unexpectedly called on the kernel stack, the RSP-addressed "NMI
executing" variable is obviously also on the kernel stack and is
"uninitialized" and can cause the NMI entry code to run in the wrong way.

Provide a non-ist entry point for VMX which shares the C-function with
the regular NMI entry and invoke the new asm entry point instead.

On 32-bit this just maps to the regular NMI entry point as 32-bit has no
ISTs and is not affected.

[ tglx: Made it independent for backporting, massaged changelog ]

Fixes: 1a5488ef0dcf6 ("KVM: VMX: Invoke NMI handler via indirect call instead of INTn")
Signed-off-by: Lai Jiangshan &lt;laijs@linux.alibaba.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Lai Jiangshan &lt;laijs@linux.alibaba.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/87r1imi8i1.ffs@nanos.tec.linutronix.de

</content>
</entry>
<entry>
<title>x86/entry: Move nmi entry/exit into common code</title>
<updated>2020-11-04T21:55:36Z</updated>
<author>
<name>Thomas Gleixner</name>
</author>
<published>2020-11-02T20:53:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b6be002bcd1dd1dedb926abf3c90c794eacb77dc'/>
<id>urn:sha1:b6be002bcd1dd1dedb926abf3c90c794eacb77dc</id>
<content type='text'>
Lockdep state handling on NMI enter and exit is nothing specific to X86. It's
not any different on other architectures. Also the extra state type is not
necessary, irqentry_state_t can carry the necessary information as well.

Move it to common code and extend irqentry_state_t to carry lockdep state.

[ Ira: Make exit_rcu and lockdep a union as they are mutually exclusive
  between the IRQ and NMI exceptions, and add kernel documentation for
  struct irqentry_state_t ]

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Ira Weiny &lt;ira.weiny@intel.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/r/20201102205320.1458656-7-ira.weiny@intel.com
</content>
</entry>
<entry>
<title>Merge tag 'x86_seves_for_v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2020-10-14T17:21:34Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2020-10-14T17:21:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=da9803dfd3955bd2f9909d55e23f188ad76dbe58'/>
<id>urn:sha1:da9803dfd3955bd2f9909d55e23f188ad76dbe58</id>
<content type='text'>
Pull x86 SEV-ES support from Borislav Petkov:
 "SEV-ES enhances the current guest memory encryption support called SEV
  by also encrypting the guest register state, making the registers
  inaccessible to the hypervisor by en-/decrypting them on world
  switches. Thus, it adds additional protection to Linux guests against
  exfiltration, control flow and rollback attacks.

  With SEV-ES, the guest is in full control of what registers the
  hypervisor can access. This is provided by a guest-host exchange
  mechanism based on a new exception vector called VMM Communication
  Exception (#VC), a new instruction called VMGEXIT and a shared
  Guest-Host Communication Block which is a decrypted page shared
  between the guest and the hypervisor.

  Intercepts to the hypervisor become #VC exceptions in an SEV-ES guest
  so in order for that exception mechanism to work, the early x86 init
  code needed to be made able to handle exceptions, which, in itself,
  brings a bunch of very nice cleanups and improvements to the early
  boot code like an early page fault handler, allowing for on-demand
  building of the identity mapping. With that, !KASLR configurations do
  not use the EFI page table anymore but switch to a kernel-controlled
  one.

  The main part of this series adds the support for that new exchange
  mechanism. The goal has been to keep this as much as possibly separate
  from the core x86 code by concentrating the machinery in two
  SEV-ES-specific files:

    arch/x86/kernel/sev-es-shared.c
    arch/x86/kernel/sev-es.c

  Other interaction with core x86 code has been kept at minimum and
  behind static keys to minimize the performance impact on !SEV-ES
  setups.

  Work by Joerg Roedel and Thomas Lendacky and others"

* tag 'x86_seves_for_v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (73 commits)
  x86/sev-es: Use GHCB accessor for setting the MMIO scratch buffer
  x86/sev-es: Check required CPU features for SEV-ES
  x86/efi: Add GHCB mappings when SEV-ES is active
  x86/sev-es: Handle NMI State
  x86/sev-es: Support CPU offline/online
  x86/head/64: Don't call verify_cpu() on starting APs
  x86/smpboot: Load TSS and getcpu GDT entry before loading IDT
  x86/realmode: Setup AP jump table
  x86/realmode: Add SEV-ES specific trampoline entry point
  x86/vmware: Add VMware-specific handling for VMMCALL under SEV-ES
  x86/kvm: Add KVM-specific VMMCALL handling under SEV-ES
  x86/paravirt: Allow hypervisor-specific VMMCALL handling under SEV-ES
  x86/sev-es: Handle #DB Events
  x86/sev-es: Handle #AC Events
  x86/sev-es: Handle VMMCALL Events
  x86/sev-es: Handle MWAIT/MWAITX Events
  x86/sev-es: Handle MONITOR/MONITORX Events
  x86/sev-es: Handle INVD Events
  x86/sev-es: Handle RDPMC Events
  x86/sev-es: Handle RDTSC(P) Events
  ...
</content>
</entry>
<entry>
<title>x86/nmi: Fix nmi_handle() duration miscalculation</title>
<updated>2020-10-01T12:42:08Z</updated>
<author>
<name>Libing Zhou</name>
</author>
<published>2020-08-20T02:56:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f94c91f7ba3ba7de2bc8aa31be28e1abb22f849e'/>
<id>urn:sha1:f94c91f7ba3ba7de2bc8aa31be28e1abb22f849e</id>
<content type='text'>
When nmi_check_duration() is checking the time an NMI handler took to
execute, the whole_msecs value used should be read from the @duration
argument, not from the -&gt;max_duration, the latter being used to store
the current maximal duration.

 [ bp: Rewrite commit message. ]

Fixes: 248ed51048c4 ("x86/nmi: Remove irq_work from the long duration NMI handler")
Suggested-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Signed-off-by: Libing Zhou &lt;libing.zhou@nokia-sbell.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Changbin Du &lt;changbin.du@gmail.com&gt;
Link: https://lkml.kernel.org/r/20200820025641.44075-1-libing.zhou@nokia-sbell.com
</content>
</entry>
<entry>
<title>x86/sev-es: Handle NMI State</title>
<updated>2020-09-09T16:02:35Z</updated>
<author>
<name>Joerg Roedel</name>
</author>
<published>2020-09-07T13:16:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4ca68e023b11e4d5908bf9ee326fab01111d77d5'/>
<id>urn:sha1:4ca68e023b11e4d5908bf9ee326fab01111d77d5</id>
<content type='text'>
When running under SEV-ES, the kernel has to tell the hypervisor when to
open the NMI window again after an NMI was injected. This is done with
an NMI-complete message to the hypervisor.

Add code to the kernel's NMI handler to send this message right at the
beginning of do_nmi(). This always allows nesting NMIs.

 [ bp: Mark __sev_es_nmi_complete() noinstr:
   vmlinux.o: warning: objtool: exc_nmi()+0x17: call to __sev_es_nmi_complete()
	leaves .noinstr.text section
   While at it, use __pa_nodebug() for the same reason due to
   CONFIG_DEBUG_VIRTUAL=y:
   vmlinux.o: warning: objtool: __sev_es_nmi_complete()+0xd9: call to __phys_addr()
   	leaves .noinstr.text section ]

Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lkml.kernel.org/r/20200907131613.12703-71-joro@8bytes.org
</content>
</entry>
<entry>
<title>x86/sev-es: Adjust #VC IST Stack on entering NMI handler</title>
<updated>2020-09-09T09:33:19Z</updated>
<author>
<name>Joerg Roedel</name>
</author>
<published>2020-09-07T13:15:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=315562c9af3d583502b35c4b223a08d95ce69864'/>
<id>urn:sha1:315562c9af3d583502b35c4b223a08d95ce69864</id>
<content type='text'>
When an NMI hits in the #VC handler entry code before it has switched to
another stack, any subsequent #VC exception in the NMI code-path will
overwrite the interrupted #VC handler's stack.

Make sure this doesn't happen by explicitly adjusting the #VC IST entry
in the NMI handler for the time it can cause #VC exceptions.

 [ bp: Touchups, spelling fixes. ]

Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lkml.kernel.org/r/20200907131613.12703-44-joro@8bytes.org
</content>
</entry>
<entry>
<title>x86/entry: Fix NMI vs IRQ state tracking</title>
<updated>2020-07-10T10:00:01Z</updated>
<author>
<name>Peter Zijlstra</name>
</author>
<published>2020-05-27T13:50:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ba1f2b2eaa2a529dba722507c55ff3d761d325dd'/>
<id>urn:sha1:ba1f2b2eaa2a529dba722507c55ff3d761d325dd</id>
<content type='text'>
While the nmi_enter() users did
trace_hardirqs_{off_prepare,on_finish}() there was no matching
lockdep_hardirqs_*() calls to complete the picture.

Introduce idtentry_{enter,exit}_nmi() to enable proper IRQ state
tracking across the NMIs.

Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Reviewed-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lkml.kernel.org/r/20200623083721.216740948@infradead.org
</content>
</entry>
<entry>
<title>x86/entry, cpumask: Provide non-instrumented variant of cpu_is_offline()</title>
<updated>2020-06-15T12:10:09Z</updated>
<author>
<name>Peter Zijlstra</name>
</author>
<published>2020-06-03T11:32:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=14d3b376b6c3f66d62559d457d32edf565472163'/>
<id>urn:sha1:14d3b376b6c3f66d62559d457d32edf565472163</id>
<content type='text'>
vmlinux.o: warning: objtool: exc_nmi()+0x12: call to cpumask_test_cpu.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_check_crashing_cpu()+0x12: call to cpumask_test_cpu.constprop.0()leaves .noinstr.text section

  cpumask_test_cpu()
    test_bit()
      instrument_atomic_read()
      arch_test_bit()

Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
</content>
</entry>
</feed>
