linux-toradex.git/arch/s390/kvm, branch master

KVM: Protect all of kvm_vm_ioctl_create_vcpu() with kvm->lock

2026-09-26T04:49:49+00:00

When creating a vCPU, don't drop kvm->lock to when doing the bulk of actual
vCPU creation, as allowing multiple vCPUs to be created in parallel adds
significant complexity in KVM (as evidenced by the many related bugs), and
all known VMMs fully serialize vCPU creation.  Remove all manually locking
of kvm->lock from kvm_arch_vcpu_{post,}create() for obvious reasons.

For many years, "everyone" has assumed that dropping kvm->lock was done for
performance reasons optimization, e.g. to allow userspace to create all
vCPUs concurrently for latency purposes.  But as above, no known VMM does
that.  Looking at the history of this code, before commit 11ec28047118
("KVM: Convert vm lock to a mutex"), kvm->lock was a spinlock.  I.e. KVM
*had* to drop kvm->lock when doing the bulk of vCPU creation, otherwise KVM
couldn't do normal memory allocations.  When kvm->lock got turned into a
mutex for unrelated reasons, no one took advantage updated of the change to
simplify vCPU creation.  And 19 years later, everyone just assumed that KVM
continued to deal with the complexity for performance reasons.

Furthermore, naively parallelizing vCPU creation in userspace is likely a
net negative due to the overheads of task creation.  Unless a VMM carefully
avoids the extra overhead related to parallelization, e.g. spawns each
vCPU's thread before creating the vCPU, creating vCPUs concurrently is a
net *negative* up until about ~64 vCPUs, after which the times are a wash.

The absolute speed of light _is_ faster if KVM doesn't hold kvm-lock, but
at vCPU counts of ~16 or less, it's probably in the noise when considering
total VM creation time, as the added latency is less than 1ms up until 16
or so vCPUs.

On top of all that, KVM has had a *lot* of fatal bugs (most often found by
syzkaller) related to vCPUs being created while trying to do per-VM
operations (basically, see every flow that locks all vCPUs).  I.e. the
parallel vCPU creation "support" is actively harmful as the only "use case"
is for misbehaving userspace to exploit KVM bugs.

Serializing vCPU creation will allow reverting commit 97d65b544f48 ("KVM:
Check for duplicate vcpu_id as early as possible"), which had "minor" math
error: the worst case scenario isn't "256 bytes per VM", it's "256 unsigned
longs per VM", i.e. 2048 bytes per VM, which doubles the size of each VM
and pushes several architectures into order-1 allocations.

Signed-off-by: Sean Christopherson 
Tested-by: Jean-Christophe Guillain 
Tested-by: Naveen N Rao (AMD) 
Message-ID: <20260921174445.911676-5-seanjc@google.com>
Signed-off-by: Paolo Bonzini

Merge tag 'kvmarm-fixes-7.3-1' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD

2026-09-21T10:09:47+00:00

KVM/arm64 changes for 7.3, take #2

 - Invalidate the ITS translation cache when the guest changes the
   base address of the ITS tables (Fuad Tabba)

 - Skip saving ITS devices with device IDs that are out-of-bounds
   rather than failing the entire ITS save ioctl (Fuad Tabba)

 - Close race between VM teardown and invalidations of nested MMUs
   when handling MMU operations that are allowed to block
   (Lorenzo Stoakes)

 - Various fixes for the handling of the host's untrusted SVE
   configuration in pKVM (Fuad Tabba)

 - Make sure that empty SMCCC ranges based at 0 are rejected by the
   kvm_smccc_set_filter() (Karl Mehltretter)

 - Revoke the host mapping for pKVM's private stack pages, along
   with a new sanity check that all mappings in the hyp's private
   VA range have been correctly marked as hyp-owned (Fuad Tabba)

 - Lifetime fixes for the array of shadow stage-2 MMUs, ensuring that
   concurrent vCPU initialization cannot relocate in-use MMUs. Defer
   the freeing of shadow stage-2 MMUs to the point that no other users
   (e.g. MMU notifier) could reference them (Marc Zyngier)

 - Drop useless WARN when rejecting an unsupported ioctl for pKVM
   (Fuad Tabba)

 - Fix the steal_time selftest to install correctly-sized mappings for
   non-4K hosts (Sebastian Ott)

 - Correct mapping of fine-grained trap for GCSPOPX instruction
   (Mark Brown)

 - Fix KVM_BUG_ON() due to missing handling of DBGBXVR from 32-bit
   guests (Karl Mehltretter)

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci

This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.

Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.

Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook

KVM: s390: Fix race in _destroy_pages_crste()

2026-09-01T13:42:28+00:00

Use READ_ONCE() in _destroy_pages_crste() to read the crste, avoid
dereferencing the pointer multiple times.

Fixes: a2c17f9270cc ("KVM: s390: New gmap code")
Signed-off-by: Claudio Imbrenda 
Message-ID: <20260828115439.145885-9-imbrenda@linux.ibm.com>

KVM: s390: Fix potential races in dat skey functions

2026-09-01T13:42:28+00:00

When dat_cond_set_storage_key() finds a large page, it will
conditionally set the storage key in absolute memory using
large_crste_to_phys() to get the absolute address.

There is a race window between dat_entry_walk() and
large_crste_to_phys(): the large page could have been split
concurrently, and large_crste_to_phys() might be called with a crste
that does not designate a large page, leading to crashes.

Similar issues were also present in dat_set_storage_key().

dat_get_storage_key() and dat_reset_reference_bit() did instead check
for a potential concurrent splitting of the large page, but then
handled it incorrectly.

Fix by performing a READ_ONCE on the crste pointer, checking and using
the result, instead of dereferencing the pointer again. In case a race
is detacted, try dat_entry_walk() again.

Fixes: 8e03e8316eb2 ("KVM: s390: KVM page table management functions: storage keys")
Signed-off-by: Claudio Imbrenda 
Message-ID: <20260828115439.145885-8-imbrenda@linux.ibm.com>

KVM: s390: Add missing srcu in kvm_s390_set_irq_state()

2026-09-01T13:42:27+00:00

Like kvm_s390_inject_vcpu(), kvm_s390_set_irq_state() also needs the
kvm->srcu or the slots lock when performing the Store status operation.

Fix by taking kvm->srcu in kvm_s390_set_irq_state().

Fixes: ba5c1e9b6cee ("KVM: s390: interrupt subsystem, cpu timer, waitpsw")
Fixes: 062e44a9319f ("KVM: s390: Use srcu in kvm_arch_vcpu_unlocked_ioctl()")
Signed-off-by: Claudio Imbrenda 
Message-ID: <20260828115439.145885-7-imbrenda@linux.ibm.com>

KVM: s390: Move all code into s390_kvm_mmu_prepare_memory_region()

2026-09-01T13:42:27+00:00

Move all code from s390_kvm_mmu_commit_memory_region() into
s390_kvm_mmu_prepare_memory_region(). This allows the function to fail
gracefully if needed. The previous behaviour was to print a warning and
continue execution with page tables inconsistent with the memslots.

Fixes: e38c884df921 ("KVM: s390: Switch to new gmap")
Signed-off-by: Claudio Imbrenda 
Message-ID: <20260828115439.145885-6-imbrenda@linux.ibm.com>

KVM: s390: Refactor dat_set_slot()

2026-09-01T13:42:27+00:00

Refactor dat_set_slot(), _dat_slot_pte(), _dat_slot_crste(). Now they
only take a struct kvm_s390_mmu_cache as priv. For dat_delete_slot(),
mc is NULL, as no allocations should take place.

This is needed as a prerequisite to move gmap DAT table setup from
kvm_arch_commit_memory_region() to kvm_arch_prepare_memory_region().

Signed-off-by: Claudio Imbrenda 
Message-ID: <20260828115439.145885-5-imbrenda@linux.ibm.com>

KVM: s390: Fix _gaccess_shadow_fault()

2026-09-01T13:42:27+00:00

In some circumstances, it is possible that the page of nested guest
memory that is being shadowed is not present at all in the parent guest
gmap. dat_entry_walk() will not find any leaf entry and return with
-ENOENT, which will erroneously be propagated all the way to userspace.

Fix by manually calling gmap_link() on the memory of the nested guest
that is being shadowed if the mapping was not already present.

Fixes: e38c884df921 ("KVM: s390: Switch to new gmap")
Signed-off-by: Claudio Imbrenda 
Message-ID: <20260828115439.145885-4-imbrenda@linux.ibm.com>

KVM: s390: Fix compile warning for kvm_s390_update_cmma_dirty()

2026-09-01T13:42:27+00:00

The parameter "old" should be marked as const, to prevent compile-time
warnings.

Fixes: d487a24041c2 ("KVM: s390: Prepare gmap for a second KVM implementation")
Signed-off-by: Claudio Imbrenda 
Message-ID: <20260828115439.145885-3-imbrenda@linux.ibm.com>