linux.git/arch/x86/include, branch v7.2 Linux kernel source tree Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 2026-08-07T14:41:40+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-08-07T14:41:40+00:00 0150da6be1c71cd0ad9262293971cb9ea371672b Pull vkm fixes from Paolo Bonzini: "s390: - fix a lot of small bugs and races x86: - fix missing locking related to KVM_CAP_MOVE_ENC_CONTEXT_FROM - warn on creating a new page table that is the child of an invalid one, and limit damage before it's too late - disable use of INVLPGA when NPT is enabled, because it doesn't seem to flush TLBs correctly" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (26 commits) KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page KVM: SVM: Serialize accesses to the owner and mirror list with separate lock KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled KVM: s390: Fix cleanup in kvm_s390_pv_create_cpu() KVM: s390: Fix ordering when adding to SCA KVM: s390: Return -EINTR if a signal is pending while faulting-in KVM: s390: Free the mmu cache when kvm_arch_vcpu_create() fails KVM: s390: ucontrol: Add missing locking around gmap_remove_child() KVM: s390: cmma: Fix dirty tracking when removing memslot KVM: s390: Fix race in __do_essa() KVM: s390: Fix leaking of PGM_ADDRESSING to userspace KVM: s390: ucontrol: Fix sca_clear_ext_call() KVM: s390: Fix overclearing ESCA in case of error KVM: s390: Fix kvm_s390_vcpu_unsetup_cmma() KVM: s390: Do not free SCA if it was not allocated KVM: s390: Fix unlikely NULL gmap dereference s390/vfio_ccw: Implement a crw lock s390/vfio_ccw: Selectively expand io_mutex s390/vfio_ccw: Move cp cleanup out of not operational s390/vfio_ccw: Cancel existing workqueues ... 
Pull vkm fixes from Paolo Bonzini:
 "s390:

   - fix a lot of small bugs and races

  x86:

   - fix missing locking related to KVM_CAP_MOVE_ENC_CONTEXT_FROM

   - warn on creating a new page table that is the child of an invalid
     one, and limit damage before it's too late

   - disable use of INVLPGA when NPT is enabled, because it doesn't seem
     to flush TLBs correctly"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (26 commits)
  KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page
  KVM: SVM: Serialize accesses to the owner and mirror list with separate lock
  KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled
  KVM: s390: Fix cleanup in kvm_s390_pv_create_cpu()
  KVM: s390: Fix ordering when adding to SCA
  KVM: s390: Return -EINTR if a signal is pending while faulting-in
  KVM: s390: Free the mmu cache when kvm_arch_vcpu_create() fails
  KVM: s390: ucontrol: Add missing locking around gmap_remove_child()
  KVM: s390: cmma: Fix dirty tracking when removing memslot
  KVM: s390: Fix race in __do_essa()
  KVM: s390: Fix leaking of PGM_ADDRESSING to userspace
  KVM: s390: ucontrol: Fix sca_clear_ext_call()
  KVM: s390: Fix overclearing ESCA in case of error
  KVM: s390: Fix kvm_s390_vcpu_unsetup_cmma()
  KVM: s390: Do not free SCA if it was not allocated
  KVM: s390: Fix unlikely NULL gmap dereference
  s390/vfio_ccw: Implement a crw lock
  s390/vfio_ccw: Selectively expand io_mutex
  s390/vfio_ccw: Move cp cleanup out of not operational
  s390/vfio_ccw: Cancel existing workqueues
  ...
KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled 2026-08-06T13:46:46+00:00 Paolo Bonzini pbonzini@redhat.com 2026-07-23T08:15:22+00:00 26505e1b5b546e2fa9a0296b951ca158460c72d8 Red Hat is seeing multiple reports of Windows memory corruptions (and consequent BSODs) with hv-tlbflush=on, on AMD processors only. The crashes, while extremely rare, happen even with a stock configuration, but with Driver Verifier enabled they can be detected after approximately 200 VM hours. In particular, Alexander Lougovski measured the following: - on AMD Turin, 15 crashes in 3300 VM hours - on AMD Milan, 2 crashes in 500 VM hours (there are fewer hours here due to the host being smaller) - on Intel Sapphire Rapids, 0 crashes in 8000 VM hours - on AMD Turin with full TLB flush (not exactly this patch but similar), no crashes in ~2 weeks of run time which should also be ~7000 VM hours For Turin, the microcode version was 0x0b002162, which (assuming this is the same issue) should not be affected by the problem listed in https://knowledge.broadcom.com/external/article/419026/bsod-on-virtual-machines-running-on-amd.html; on the other hand that problem should not apply to earlier processors. AMD has not provided any information or analysis yet, and when we asked we didn't know yet that it reproduced on Milan as well. As to the workload, Alexander threw more or less everything at the same time at the VM: - a full Windows Defender scan every 30 minutes - a disk I/O job - a loop doing repeated mmap of system files (mostly to hope that it triggers some consistency check in the Windows memory manager) - SQL Express 2022 + StressDB (1.6M rows), with the host doing queries (75% write/25% read) via sqlcmd Driver Verifier is able to detect BSODs more or less at the same time as the pages are freed. They mostly happen in the Windows Defender filter driver, but occasionally also in the networking stack (e.g., afd.sys) or elsewhere in the filesystem stack (e.g., fltmgr.sys). The flush is issued from kvm_hv_vcpu_flush_tlb(), which receives the cross-CPU requests from the Hyper-V TLB flush hypercalls via a kfifo and is invoked by the KVM_REQ_HV_TLB_FLUSH request. The mechanism is the same for both Intel and AMD, and the handler for both vendors is a simple INVVPID(ADDR)/INVLPGA instruction. Because the request is handled on the destination CPU, there is a question of what happens if the VM is migrated across physical CPUs. In that case, the INVLPGA instruction would use a stale svm->vmcb->control.asid; but if anything that might do an *unnecessary* flush (on an asid that's being used for another VM) and then pre_svm_run() would force a full TLB rebuild. So, for lack of better ideas, this patch forces a full ASID bump in svm_flush_tlb_gva(). To avoid paying the price on Intel and also to avoid unnecessary loops on AMD, the flush_tlb_gva op now returns whether it did a full flush or not; kvm_hv_vcpu_flush_tlb() takes note and exits its loops immediately. While there is an obvious performance impact, about half of the benefit from Hyper-V tlbflush is preserved (10% vs. 20% on the SQL Server workload). kvm_mmu_invalidate_addr() is the only other caller of the flush_tlb_gva op. The change would have a performance impact on every intercepted INVLPG and, for nested SVM, on every L1 INVLPGA. For INVLPGA specifically, this covers the same suspected issue but for nested hypervisors, so it is correct to apply the workaround; for INVLPG on shadow paging, instead, the impact would be stronger and, due to lack of data, for now the use of INVLPGA is left in place in svm_flush_tlb_gva(). Analyzed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Analyzed-by: Alexander Lougovski <alougovs@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 
Red Hat is seeing multiple reports of Windows memory corruptions
(and consequent BSODs) with hv-tlbflush=on, on AMD processors only.
The crashes, while extremely rare, happen even with a stock configuration,
but with Driver Verifier enabled they can be detected after approximately
200 VM hours.  In particular, Alexander Lougovski measured the following:

- on AMD Turin, 15 crashes in 3300 VM hours

- on AMD Milan, 2 crashes in 500 VM hours (there are fewer hours
  here due to the host being smaller)

- on Intel Sapphire Rapids, 0 crashes in 8000 VM hours

- on AMD Turin with full TLB flush (not exactly this patch but
  similar), no crashes in ~2 weeks of run time which should also
  be ~7000 VM hours

For Turin, the microcode version was 0x0b002162, which (assuming
this is the same issue) should not be affected by the problem listed in
https://knowledge.broadcom.com/external/article/419026/bsod-on-virtual-machines-running-on-amd.html;
on the other hand that problem should not apply to earlier processors.
AMD has not provided any information or analysis yet, and when we asked
we didn't know yet that it reproduced on Milan as well.

As to the workload, Alexander threw more or less everything at the same
time at the VM:

- a full Windows Defender scan every 30 minutes

- a disk I/O job

- a loop doing repeated mmap of system files (mostly to hope that
  it triggers some consistency check in the Windows memory manager)

- SQL Express 2022 + StressDB (1.6M rows), with the host doing queries
  (75% write/25% read) via sqlcmd

Driver Verifier is able to detect BSODs more or less at the same time as
the pages are freed.  They mostly happen in the Windows Defender filter
driver, but occasionally also in the networking stack (e.g., afd.sys)
or elsewhere in the filesystem stack (e.g., fltmgr.sys).

The flush is issued from kvm_hv_vcpu_flush_tlb(), which receives the
cross-CPU requests from the Hyper-V TLB flush hypercalls via a kfifo
and is invoked by the KVM_REQ_HV_TLB_FLUSH request.  The mechanism is
the same for both Intel and AMD, and the handler for both vendors is
a simple INVVPID(ADDR)/INVLPGA instruction.

Because the request is handled on the destination CPU, there is a question
of what happens if the VM is migrated across physical CPUs.  In that case,
the INVLPGA instruction would use a stale svm->vmcb->control.asid; but
if anything that might do an *unnecessary* flush (on an asid that's being
used for another VM) and then pre_svm_run() would force a full TLB rebuild.

So, for lack of better ideas, this patch forces a full ASID bump in
svm_flush_tlb_gva().  To avoid paying the price on Intel and also to
avoid unnecessary loops on AMD, the flush_tlb_gva op now returns whether
it did a full flush or not; kvm_hv_vcpu_flush_tlb() takes note and exits
its loops immediately.  While there is an obvious performance impact,
about half of the benefit from Hyper-V tlbflush is preserved (10% vs. 20%
on the SQL Server workload).

kvm_mmu_invalidate_addr() is the only other caller of the flush_tlb_gva op.
The change would have a performance impact on every intercepted INVLPG and,
for nested SVM, on every L1 INVLPGA.  For INVLPGA specifically, this covers
the same suspected issue but for nested hypervisors, so it is correct to
apply the workaround; for INVLPG on shadow paging, instead, the impact
would be stronger and, due to lack of data, for now the use of INVLPGA is
left in place in svm_flush_tlb_gva().

Analyzed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Analyzed-by: Alexander Lougovski <alougovs@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
x86/bugs: Make Safe-RET robust against interrupt injection 2026-07-26T14:21:37+00:00 Borislav Petkov (AMD) bp@alien8.de 2026-06-03T04:26:44+00:00 7e7f81cf6f5ca3311e526308f55d7c54d3ba71f9 An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by "emulating" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt. Co-developed-by: David Kaplan <David.Kaplan@amd.com> Signed-off-by: David Kaplan <David.Kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> 
An attacker injecting interrupts while the Safe-RET mitigation executes
on machines affected by SRSO can neutralize the safe return sequence,
potentially leading to data leakage through speculative execution.

Fixup register state as if the Safe-RET sequence executed successfully
by "emulating" it, in a manner of speaking, and avoid executing a RET
instruction after returning from the interrupt.

Co-developed-by: David Kaplan <David.Kaplan@amd.com>
Signed-off-by: David Kaplan <David.Kaplan@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Merge tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux 2026-07-03T06:54:26+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-07-03T06:54:26+00:00 d2c9a99135da931377240942d44f3dea104cedb8 Pull mod_devicetable.h header split from Uwe Kleine-König: "Split <linux/mod_devicetable.h> in per subsystem headers <linux/mod_devicetable.h> is included transitively in nearly every driver in an x86_64 allmodconfig build of v7.1: $ find drivers -name \*.o -not -name \*.mod.o | wc -l 21330 $ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l 17038 The result of this mixture of different and unrelated subsystem details is that even when touching an obscure device id struct most of the kernel needs to be recompiled. Given that each driver typically only needs one or two of these structures, splitting into per subsystem headers and only including what is really needed reduces the amount of needed recompilation. This split is implemented in the first commit and then after some preparatory work in the following commits, the last two replace includes of <linux/mod_devicetable.h> by the actually needed more specific headers. There are still a few instances left, but the ones with high impact (that is in headers that are used a lot) and the easy ones (.c files) are handled. These remaining includes will be addressed during the next merge window" * tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files) Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (headers) parisc: #include <linux/compiler.h> for unlikely() in <asm/ptrace.h> media: em28xx: Add include for struct usb_device_id LoongArch: KVM: Add include defining struct cpu_feature ALSA: hda/core: Add include defining struct hda_device_id usb: dwc2: Add include defining struct pci_device_id platform/x86: int3472: Add include defining struct dmi_system_id platform/x86: x86-android-tablets: Add include defining struct dmi_system_id i2c: Let i2c-core.h include <linux/i2c.h> of: Explicitly include <linux/types.h> and <linux/err.h> platform/x86: msi-ec: Ensure dmi_system_id is defined usb: serial: Include <linux/usb.h> in <linux/usb/serial.h> driver core: platform: Include header for struct platform_device_id driver: core: Include headers for acpi_device_id and of_device_id for struct device_driver media: ti: vpe: #include <linux/platform_device.h> explicitly mod_devicetable.h: Split into per subsystem headers 
Pull mod_devicetable.h header split from Uwe Kleine-König:
 "Split <linux/mod_devicetable.h> in per subsystem headers

  <linux/mod_devicetable.h> is included transitively in nearly every
  driver in an x86_64 allmodconfig build of v7.1:

      $ find drivers -name \*.o -not -name \*.mod.o | wc -l
      21330
      $ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l
      17038

  The result of this mixture of different and unrelated subsystem
  details is that even when touching an obscure device id struct most of
  the kernel needs to be recompiled. Given that each driver typically
  only needs one or two of these structures, splitting into per
  subsystem headers and only including what is really needed reduces the
  amount of needed recompilation.

  This split is implemented in the first commit and then after some
  preparatory work in the following commits, the last two replace
  includes of <linux/mod_devicetable.h> by the actually needed more
  specific headers.

  There are still a few instances left, but the ones with high impact
  (that is in headers that are used a lot) and the easy ones (.c files)
  are handled. These remaining includes will be addressed during the
  next merge window"

* tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux:
  Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files)
  Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (headers)
  parisc: #include <linux/compiler.h> for unlikely() in <asm/ptrace.h>
  media: em28xx: Add include for struct usb_device_id
  LoongArch: KVM: Add include defining struct cpu_feature
  ALSA: hda/core: Add include defining struct hda_device_id
  usb: dwc2: Add include defining struct pci_device_id
  platform/x86: int3472: Add include defining struct dmi_system_id
  platform/x86: x86-android-tablets: Add include defining struct dmi_system_id
  i2c: Let i2c-core.h include <linux/i2c.h>
  of: Explicitly include <linux/types.h> and <linux/err.h>
  platform/x86: msi-ec: Ensure dmi_system_id is defined
  usb: serial: Include <linux/usb.h> in <linux/usb/serial.h>
  driver core: platform: Include header for struct platform_device_id
  driver: core: Include headers for acpi_device_id and of_device_id for struct device_driver
  media: ti: vpe: #include <linux/platform_device.h> explicitly
  mod_devicetable.h: Split into per subsystem headers
Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (headers) 2026-07-03T05:38:16+00:00 Uwe Kleine-König (The Capable Hub) u.kleine-koenig@baylibre.com 2026-06-30T09:24:35+00:00 ecca1d63c1eadbbb38ceab82de0f7adfbc2b465d <linux/mod_devicetable.h> is included in a many files: $ git grep '<linux/mod_devicetable.h>' ef0c9f75a195 | wc -l 1598 ; some of them are widely used headers. To stop mixing up different and unrelated driver( type)s let the subsystem headers only use the subset of the recently split <linux/mod_devicetable.h> that are relevant for them. The fallout (I hope) is addressed in the previous commits that handle sources relying on e.g. <linux/i2c.h> pulling in the full legacy header and thus providing pci_device_id. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://patch.msgid.link/199fe46b624ba07fb9bd3e0cd6ff13757932cb5f.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> 
<linux/mod_devicetable.h> is included in a many files:

	$ git grep '<linux/mod_devicetable.h>' ef0c9f75a195 | wc -l
	1598

; some of them are widely used headers. To stop mixing up different and
unrelated driver( type)s let the subsystem headers only use the subset
of the recently split <linux/mod_devicetable.h> that are relevant for
them.

The fallout (I hope) is addressed in the previous commits that handle
sources relying on e.g. <linux/i2c.h> pulling in the full legacy header
and thus providing pci_device_id.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/199fe46b624ba07fb9bd3e0cd6ff13757932cb5f.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
x86/bugs: Enable IBPB flush on BPF JIT allocation 2026-07-01T08:33:38+00:00 Pawan Gupta pawan.kumar.gupta@linux.intel.com 2026-06-30T05:38:07+00:00 a3af84b0fa00ead01fcd0e28b5d773ff25990a0d Enable hardening against JIT spraying when Spectre-v2 mitigations are in use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip enabling the IBPB flush if the BPF dispatcher is already using a retpoline sequence. This hardening applies only when BPF-JIT is in use. Guard the enabling under CONFIG_BPF_JIT so that bugs.c still builds with CONFIG_BPF_JIT=n. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> 
Enable hardening against JIT spraying when Spectre-v2 mitigations are in
use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip
enabling the IBPB flush if the BPF dispatcher is already using a retpoline
sequence.

This hardening applies only when BPF-JIT is in use. Guard the enabling
under CONFIG_BPF_JIT so that bugs.c still builds with CONFIG_BPF_JIT=n.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 2026-06-25T17:21:13+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-06-25T17:21:13+00:00 c75597caada080effbfbc0a7fb10dc2a3bb543ad Pull kvm fixes from Paolo Bonzini: "s390: - Fix S390_USER_OPEREXEC so it can now be enabled regardless of other unrelated capabilities - Fix handling of the _PAGE_UNUSED pte bit that could lead to guest memory corruption in some scenarios - A bunch of misc gmap fixes (locking, behaviour under memory pressure) - Fix CMMA dirty tracking x86: - Tidy up some WARN_ON() and BUG_ON(), replacing them with WARN_ON_ONCE() or KVM_BUG_ON(). All of these have obviously never triggered, or somebody would have been annoyed earlier, but still... - Fix missing interrupt due to stale CR8 intercept - Add a statistic that can come in handy to debug leaks as well as the vulnerability to a class of recently-discovered issues - Do not ask arch/x86/kernel to export default_cpu_present_to_apicid() just for KVM" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (22 commits) x86/apic: KVM: Use cpu_physical_id() to get APIC ID of running vCPU for AVIC KVM: x86/mmu: Expose number of shadow MMU shadow pages as a stat KVM: x86: Unconditionally recompute CR8 intercept on PPR update KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode KVM: x86: WARN (once) if RTC pending EOI tracking goes off the rails KVM: x86: WARN and fail kvm_set_irq() if a PIC or I/O APIC vector is invalid KVM: x86: Bug the VM, not the kernel, if the ISR count {under,over}flows KVM: x86/mmu: Bug the VM, not the host kernel, if KVM write-protects upper SPTEs KVM: x86: Replace BUG_ON() with WARN_ON_ONCE() on "bad" nested GPA translation KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() KVM: s390: Return failure in case of failure in kvm_s390_set_cmma_bits() KVM: s390: selftests: Fix cmma selftest KVM: s390: Fix cmma dirty tracking KVM: s390: Fix locking in kvm_s390_set_mem_control() KVM: s390: Fix handle_{sske,pfmf} under memory pressure KVM: s390: Fix code typo in gmap_protect_asce_top_level() KVM: s390: Do not set special large pages dirty KVM: s390: Fix dat_peek_cmma() overflow s390/mm: Fix handling of _PAGE_UNUSED pte bit KVM: s390: Fix typo in UCONTROL documentation ... 
Pull kvm fixes from Paolo Bonzini:
 "s390:

   - Fix S390_USER_OPEREXEC so it can now be enabled regardless of other
     unrelated capabilities

   - Fix handling of the _PAGE_UNUSED pte bit that could lead to guest
     memory corruption in some scenarios

   - A bunch of misc gmap fixes (locking, behaviour under memory
     pressure)

   - Fix CMMA dirty tracking

  x86:

   - Tidy up some WARN_ON() and BUG_ON(), replacing them with
     WARN_ON_ONCE() or KVM_BUG_ON(). All of these have obviously never
     triggered, or somebody would have been annoyed earlier, but still...

   - Fix missing interrupt due to stale CR8 intercept

   - Add a statistic that can come in handy to debug leaks as well as
     the vulnerability to a class of recently-discovered issues

   - Do not ask arch/x86/kernel to export
     default_cpu_present_to_apicid() just for KVM"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (22 commits)
  x86/apic: KVM: Use cpu_physical_id() to get APIC ID of running vCPU for AVIC
  KVM: x86/mmu: Expose number of shadow MMU shadow pages as a stat
  KVM: x86: Unconditionally recompute CR8 intercept on PPR update
  KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode
  KVM: x86: WARN (once) if RTC pending EOI tracking goes off the rails
  KVM: x86: WARN and fail kvm_set_irq() if a PIC or I/O APIC vector is invalid
  KVM: x86: Bug the VM, not the kernel, if the ISR count {under,over}flows
  KVM: x86/mmu: Bug the VM, not the host kernel, if KVM write-protects upper SPTEs
  KVM: x86: Replace BUG_ON() with WARN_ON_ONCE() on "bad" nested GPA translation
  KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned()
  KVM: s390: Return failure in case of failure in kvm_s390_set_cmma_bits()
  KVM: s390: selftests: Fix cmma selftest
  KVM: s390: Fix cmma dirty tracking
  KVM: s390: Fix locking in kvm_s390_set_mem_control()
  KVM: s390: Fix handle_{sske,pfmf} under memory pressure
  KVM: s390: Fix code typo in gmap_protect_asce_top_level()
  KVM: s390: Do not set special large pages dirty
  KVM: s390: Fix dat_peek_cmma() overflow
  s390/mm: Fix handling of _PAGE_UNUSED pte bit
  KVM: s390: Fix typo in UCONTROL documentation
  ...
x86/apic: KVM: Use cpu_physical_id() to get APIC ID of running vCPU for AVIC 2026-06-24T11:52:24+00:00 Sean Christopherson seanjc@google.com 2026-06-12T18:54:59+00:00 098e32cba334da0f3fa8cfd4e022ae7c72341400 Use cpu_physical_id() instead of default_cpu_present_to_apicid() when getting the APIC ID of the pCPU on which a vCPU is running/loaded, as the kernel has gone way off the rails if a vCPU is loaded on a pCPU that has been physically removed from the system. Even if the impossible were to happen, the absolutely worst case scenario is that hardware will ring the AIVC doorbell on the wrong pCPU, i.e. a severely broken system will experience mild performance issues. Kill off KVM's superfluous kvm_cpu_get_apicid() wrapper along with the for-KVM export of default_cpu_present_to_apicid(), as they existed purely for the wonky AVIC usage. Cc: Kai Huang <kai.huang@intel.com> Cc: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Acked-by: Naveen N Rao (AMD) <naveen@kernel.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Message-ID: <20260612185459.591892-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 
Use cpu_physical_id() instead of default_cpu_present_to_apicid() when
getting the APIC ID of the pCPU on which a vCPU is running/loaded, as the
kernel has gone way off the rails if a vCPU is loaded on a pCPU that has
been physically removed from the system.  Even if the impossible were to
happen, the absolutely worst case scenario is that hardware will ring the
AIVC doorbell on the wrong pCPU, i.e. a severely broken system will
experience mild performance issues.

Kill off KVM's superfluous kvm_cpu_get_apicid() wrapper along with the
for-KVM export of default_cpu_present_to_apicid(), as they existed purely
for the wonky AVIC usage.

Cc: Kai Huang <kai.huang@intel.com>
Cc: Yosry Ahmed <yosry@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Acked-by: Naveen N Rao (AMD) <naveen@kernel.org>
Reviewed-by: Kai Huang <kai.huang@intel.com>
Reviewed-by: Yosry Ahmed <yosry@kernel.org>
Message-ID: <20260612185459.591892-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
KVM: x86/mmu: Expose number of shadow MMU shadow pages as a stat 2026-06-24T11:52:23+00:00 Sean Christopherson seanjc@google.com 2026-06-12T13:37:27+00:00 02953418a1378514d1f4086180f14004f5d08ea5 Turn arch.n_used_mmu_pages into a stat, mmu_shadow_pages, as the number of live shadow pages is arguably _the_ most critical datapoint when it comes to analyzing the shadow MMU. Before the TDP MMU came along, i.e. when the shadow MMU was the only MMU, explicitly tracking the number of shadow pages wasn't as interesting, because the same information could more or less be gleaned from the pages_{1g,2m,4k} stats. But with the TDP MMU, where the shadow MMU is only used for nested TDP, it becomes extremely difficult, if not impossible, to determine which SPTEs are coming from the TDP MMU, and which are coming from the shadow MMU. E.g. when triaging/debugging shadow MMU performance issues due to "too many shadow pages", being able to observe that 99%+ of all shadow pages are unsync is critical to being able to deduce that KVM is effectively leaking shadow pages. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260612133727.411902-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 
Turn arch.n_used_mmu_pages into a stat, mmu_shadow_pages, as the number of
live shadow pages is arguably _the_ most critical datapoint when it comes
to analyzing the shadow MMU.  Before the TDP MMU came along, i.e. when the
shadow MMU was the only MMU, explicitly tracking the number of shadow pages
wasn't as interesting, because the same information could more or less be
gleaned from the pages_{1g,2m,4k} stats.  But with the TDP MMU, where the
shadow MMU is only used for nested TDP, it becomes extremely difficult, if
not impossible, to determine which SPTEs are coming from the TDP MMU, and
which are coming from the shadow MMU.

E.g. when triaging/debugging shadow MMU performance issues due to "too many
shadow pages", being able to observe that 99%+ of all shadow pages are
unsync is critical to being able to deduce that KVM is effectively leaking
shadow pages.

Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260612133727.411902-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Merge tag 'hyperv-next-signed-20260621' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux 2026-06-22T15:06:13+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-06-22T15:06:13+00:00 6e869de3a1b9ef9f096223e0e7f30c727de4f6bc Pull hyperv updates from Wei Liu: - Use wakeup mailbox to boot APs in Hyper-V VTL2 TDX guests (Yunhong Jiang, Ricardo Neri) - Move the Hyper-V IOMMU to its own subdirectory (Mukesh Rathor) - Cosmetic changes to mshv and balloon driver (Junrui Luo, Markus Elfring) * tag 'hyperv-next-signed-20260621' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: mshv: add bounds check on vp_index in mshv_intercept_isr() hv_balloon: Simplify data output in hv_balloon_debug_show() x86/hyperv: Cosmetic changes in irqdomain.c for readability iommu/hyperv: Create hyperv subdirectory under drivers/iommu x86/hyperv/vtl: Use the wakeup mailbox to boot secondary CPUs x86/hyperv/vtl: Mark the wakeup mailbox page as private x86/acpi: Add a helper to get the address of the wakeup mailbox x86/hyperv/vtl: Setup the 64-bit trampoline for TDX guests x86/realmode: Make the location of the trampoline configurable x86/hyperv/vtl: Set real_mode_header in hv_vtl_init_platform() x86/dt: Parse the Wakeup Mailbox for Intel processors dt-bindings: reserved-memory: Wakeup Mailbox for Intel processors x86/acpi: Add functions to setup and access the wakeup mailbox x86/topology: Add missing struct declaration and attribute dependency 
Pull hyperv updates from Wei Liu:

 - Use wakeup mailbox to boot APs in Hyper-V VTL2 TDX guests (Yunhong
   Jiang, Ricardo Neri)

 - Move the Hyper-V IOMMU to its own subdirectory (Mukesh Rathor)

 - Cosmetic changes to mshv and balloon driver (Junrui Luo, Markus
   Elfring)

* tag 'hyperv-next-signed-20260621' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
  mshv: add bounds check on vp_index in mshv_intercept_isr()
  hv_balloon: Simplify data output in hv_balloon_debug_show()
  x86/hyperv: Cosmetic changes in irqdomain.c for readability
  iommu/hyperv: Create hyperv subdirectory under drivers/iommu
  x86/hyperv/vtl: Use the wakeup mailbox to boot secondary CPUs
  x86/hyperv/vtl: Mark the wakeup mailbox page as private
  x86/acpi: Add a helper to get the address of the wakeup mailbox
  x86/hyperv/vtl: Setup the 64-bit trampoline for TDX guests
  x86/realmode: Make the location of the trampoline configurable
  x86/hyperv/vtl: Set real_mode_header in hv_vtl_init_platform()
  x86/dt: Parse the Wakeup Mailbox for Intel processors
  dt-bindings: reserved-memory: Wakeup Mailbox for Intel processors
  x86/acpi: Add functions to setup and access the wakeup mailbox
  x86/topology: Add missing struct declaration and attribute dependency