kernel/linux.git/arch/s390/include/asm/uv.h, branch linux-7.0.y

KVM: s390: Switch to new gmap

2026-02-04T16:00:10+00:00

Switch KVM/s390 to use the new gmap code. Remove includes to and include "gmap.h" instead; fix all the existing users of the old gmap functions to use the new ones instead. Fix guest storage key access functions to work with the new gmap. Acked-by: Heiko Carstens Signed-off-by: Claudio Imbrenda

KVM: s390: Export two functions

2026-02-04T16:00:08+00:00

Export __make_folio_secure() and s390_wiggle_split_folio(), as they will be needed to be used by KVM. Acked-by: Heiko Carstens Signed-off-by: Claudio Imbrenda

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

2025-06-02T19:24:58+00:00

Pull more kvm updates from Paolo Bonzini: Generic: - Clean up locking of all vCPUs for a VM by using the *_nest_lock() family of functions, and move duplicated code to virt/kvm/. kernel/ patches acked by Peter Zijlstra - Add MGLRU support to the access tracking perf test ARM fixes: - Make the irqbypass hooks resilient to changes in the GSI<->MSI routing, avoiding behind stale vLPI mappings being left behind. The fix is to resolve the VGIC IRQ using the host IRQ (which is stable) and nuking the vLPI mapping upon a routing change - Close another VGIC race where vCPU creation races with VGIC creation, leading to in-flight vCPUs entering the kernel w/o private IRQs allocated - Fix a build issue triggered by the recently added workaround for Ampere's AC04_CPU_23 erratum - Correctly sign-extend the VA when emulating a TLBI instruction potentially targeting a VNCR mapping - Avoid dereferencing a NULL pointer in the VGIC debug code, which can happen if the device doesn't have any mapping yet s390: - Fix interaction between some filesystems and Secure Execution - Some cleanups and refactorings, preparing for an upcoming big series x86: - Wait for target vCPU to ack KVM_REQ_UPDATE_PROTECTED_GUEST_STATE to fix a race between AP destroy and VMRUN - Decrypt and dump the VMSA in dump_vmcb() if debugging enabled for the VM - Refine and harden handling of spurious faults - Add support for ALLOWED_SEV_FEATURES - Add #VMGEXIT to the set of handlers special cased for CONFIG_RETPOLINE=y - Treat DEBUGCTL[5:2] as reserved to pave the way for virtualizing features that utilize those bits - Don't account temporary allocations in sev_send_update_data() - Add support for KVM_CAP_X86_BUS_LOCK_EXIT on SVM, via Bus Lock Threshold - Unify virtualization of IBRS on nested VM-Exit, and cross-vCPU IBPB, between SVM and VMX - Advertise support to userspace for WRMSRNS and PREFETCHI - Rescan I/O APIC routes after handling EOI that needed to be intercepted due to the old/previous routing, but not the new/current routing - Add a module param to control and enumerate support for device posted interrupts - Fix a potential overflow with nested virt on Intel systems running 32-bit kernels - Flush shadow VMCSes on emergency reboot - Add support for SNP to the various SEV selftests - Add a selftest to verify fastops instructions via forced emulation - Refine and optimize KVM's software processing of the posted interrupt bitmap, and share the harvesting code between KVM and the kernel's Posted MSI handler" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (93 commits) rtmutex_api: provide correct extern functions KVM: arm64: vgic-debug: Avoid dereferencing NULL ITE pointer KVM: arm64: vgic-init: Plug vCPU vs. VGIC creation race KVM: arm64: Unmap vLPIs affected by changes to GSI routing information KVM: arm64: Resolve vLPI by host IRQ in vgic_v4_unset_forwarding() KVM: arm64: Protect vLPI translation with vgic_irq::irq_lock KVM: arm64: Use lock guard in vgic_v4_set_forwarding() KVM: arm64: Mask out non-VA bits from TLBI VA* on VNCR invalidation arm64: sysreg: Drag linux/kconfig.h to work around vdso build issue KVM: s390: Simplify and move pv code KVM: s390: Refactor and split some gmap helpers KVM: s390: Remove unneeded srcu lock s390: Remove unneeded includes s390/uv: Improve splitting of large folios that cannot be split while dirty s390/uv: Always return 0 from s390_wiggle_split_folio() if successful s390/uv: Don't return 0 from make_hva_secure() if the operation was not successful rust: add helper for mutex_trylock RISC-V: KVM: use kvm_trylock_all_vcpus when locking all vCPUs KVM: arm64: use kvm_trylock_all_vcpus when locking all vCPUs x86: KVM: SVM: use kvm_lock_all_vcpus instead of a custom implementation ...

s390: Remove unneeded includes

2025-05-28T15:48:04+00:00

Many files don't need to include asm/tlb.h or asm/gmap.h. On the other hand, asm/tlb.h does need to include asm/gmap.h. Remove all unneeded includes so that asm/tlb.h is not directly used by s390 arch code anymore. Remove asm/gmap.h from a few other files as well, so that now only KVM code, mm/gmap.c, and asm/tlb.h include it. Reviewed-by: Christoph Schlameuss Reviewed-by: Steffen Eiden Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20250528095502.226213-2-imbrenda@linux.ibm.com Signed-off-by: Claudio Imbrenda Message-ID: <20250528095502.226213-2-imbrenda@linux.ibm.com>

s390/uv: Remove uv_get_secret_metadata function

2025-04-30T09:34:03+00:00

The uv_get_secret_metadata() in-kernel function was only offered and used by the pkey uv handler. Remove it as there is no customer any more. Suggested-by: Steffen Eiden Signed-off-by: Harald Freudenberger Reviewed-by: Steffen Eiden Acked-by: Holger Dengler Link: https://lore.kernel.org/r/20250424133619.16495-24-freude@linux.ibm.com Signed-off-by: Heiko Carstens

s390/uv: Rename find_secret() to uv_find_secret() and publish

2025-04-30T09:34:03+00:00

Rename the internal UV function find_secret() to uv_find_secret() and publish it as new UV API in-kernel function. The pkey uv handler may be called in a do-not-allocate memory situation where sleeping is allowed but allocating memory which may cause IO operations is not. For example when an encrypted swap file is used and the encryption is done via UV retrievable secrets with protected keys. The UV API function uv_get_secret_metadata() allocates memory and then calls the find_secret() function. By exposing the find_secret() function as a new UV API function uv_find_secret() it is possible to retrieve UV secret meta data without any memory allocations from the UV when the caller offers space for one struct uv_secret_list. Signed-off-by: Harald Freudenberger Reviewed-by: Steffen Eiden Acked-by: Holger Dengler Link: https://lore.kernel.org/r/20250424133619.16495-22-freude@linux.ibm.com Signed-off-by: Heiko Carstens

KVM: s390: pv: fix race when making a page secure

2025-03-14T14:24:19+00:00

Holding the pte lock for the page that is being converted to secure is needed to avoid races. A previous commit removed the locking, which caused issues. Fix by locking the pte again. Fixes: 5cbe24350b7d ("KVM: s390: move pv gmap functions into kvm") Reported-by: David Hildenbrand Tested-by: David Hildenbrand Reviewed-by: David Hildenbrand [david@redhat.com: replace use of get_locked_pte() with folio_walk_start()] Link: https://lore.kernel.org/r/20250312184912.269414-2-imbrenda@linux.ibm.com Signed-off-by: Claudio Imbrenda Message-ID: <20250312184912.269414-2-imbrenda@linux.ibm.com>

KVM: s390: move pv gmap functions into kvm

2025-01-31T11:03:52+00:00

Move gmap related functions from kernel/uv into kvm. Create a new file to collect gmap-related functions. Reviewed-by: Janosch Frank Reviewed-by: Christoph Schlameuss [fixed unpack_one(), thanks mhartmay@linux.ibm.com] Link: https://lore.kernel.org/r/20250123144627.312456-6-imbrenda@linux.ibm.com Signed-off-by: Claudio Imbrenda Message-ID: <20250123144627.312456-6-imbrenda@linux.ibm.com>

s390/uv: Convert to use flag output macros

2024-11-13T13:31:32+00:00

Use flag output macros in inline asm to allow for better code generation if the compiler has support for the flag output constraint. Reviewed-by: Juergen Christ Signed-off-by: Heiko Carstens

s390/uv: Retrieve UV secrets sysfs support

2024-10-29T10:17:17+00:00

Reflect the updated content in the query information UVC to the sysfs at /sys/firmware/query * new UV-query sysfs entry for the maximum number of retrievable secrets the UV can store for one secure guest. * new UV-query sysfs entry for the maximum number of association secrets the UV can store for one secure guest. * max_secrets contains the sum of max association and max retrievable secrets. Reviewed-by: Christoph Schlameuss Signed-off-by: Steffen Eiden Link: https://lore.kernel.org/r/20241024062638.1465970-7-seiden@linux.ibm.com Signed-off-by: Janosch Frank Signed-off-by: Heiko Carstens