kernel/arch/s390/kvm/pv.c, branch linux-6.2.y

KVM: s390: pv: fix asynchronous teardown for small VMs

2023-05-17T11:58:50Z

[ Upstream commit 292a7d6fca33df70ca4b8e9b0d0e74adf87582dc ] On machines without the Destroy Secure Configuration Fast UVC, the topmost level of page tables is set aside and freed asynchronously as last step of the asynchronous teardown. Each gmap has a host_to_guest radix tree mapping host (userspace) addresses (with 1M granularity) to gmap segment table entries (pmds). If a guest is smaller than 2GB, the topmost level of page tables is the segment table (i.e. there are only 2 levels). Replacing it means that the pointers in the host_to_guest mapping would become stale and cause all kinds of nasty issues. This patch fixes the issue by disallowing asynchronous teardown for guests with only 2 levels of page tables. Userspace should (and already does) try using the normal destroy if the asynchronous one fails. Update s390_replace_asce so it refuses to replace segment type ASCEs. This is still needed in case the normal destroy VM fails. Fixes: fb491d5500a7 ("KVM: s390: pv: asynchronous destroy for reboot") Reviewed-by: Marc Hartmayer Reviewed-by: Janosch Frank Signed-off-by: Claudio Imbrenda Message-Id: <20230421085036.52511-2-imbrenda@linux.ibm.com> Signed-off-by: Sasha Levin

KVM: s390: pv: support for Destroy fast UVC

2022-11-23T09:06:50Z

Add support for the Destroy Secure Configuration Fast Ultravisor call, and take advantage of it for asynchronous destroy. When supported, the protected guest is destroyed immediately using the new UVC, leaving only the memory to be cleaned up asynchronously. Signed-off-by: Claudio Imbrenda Reviewed-by: Nico Boehr Reviewed-by: Janosch Frank Reviewed-by: Steffen Eiden Link: https://lore.kernel.org/r/20221111170632.77622-6-imbrenda@linux.ibm.com Message-Id: <20221111170632.77622-6-imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank

KVM: s390: pv: asynchronous destroy for reboot

2022-11-23T09:06:50Z

Until now, destroying a protected guest was an entirely synchronous operation that could potentially take a very long time, depending on the size of the guest, due to the time needed to clean up the address space from protected pages. This patch implements an asynchronous destroy mechanism, that allows a protected guest to reboot significantly faster than previously. This is achieved by clearing the pages of the old guest in background. In case of reboot, the new guest will be able to run in the same address space almost immediately. The old protected guest is then only destroyed when all of its memory has been destroyed or otherwise made non protected. Two new PV commands are added for the KVM_S390_PV_COMMAND ioctl: KVM_PV_ASYNC_CLEANUP_PREPARE: set aside the current protected VM for later asynchronous teardown. The current KVM VM will then continue immediately as non-protected. If a protected VM had already been set aside for asynchronous teardown, but without starting the teardown process, this call will fail. There can be at most one VM set aside at any time. Once it is set aside, the protected VM only exists in the context of the Ultravisor, it is not associated with the KVM VM anymore. Its protected CPUs have already been destroyed, but not its memory. This command can be issued again immediately after starting KVM_PV_ASYNC_CLEANUP_PERFORM, without having to wait for completion. KVM_PV_ASYNC_CLEANUP_PERFORM: tears down the protected VM previously set aside using KVM_PV_ASYNC_CLEANUP_PREPARE. Ideally the KVM_PV_ASYNC_CLEANUP_PERFORM PV command should be issued by userspace from a separate thread. If a fatal signal is received (or if the process terminates naturally), the command will terminate immediately without completing. All protected VMs whose teardown was interrupted will be put in the need_cleanup list. The rest of the normal KVM teardown process will take care of properly cleaning up all remaining protected VMs, including the ones on the need_cleanup list. Signed-off-by: Claudio Imbrenda Reviewed-by: Nico Boehr Reviewed-by: Janosch Frank Reviewed-by: Steffen Eiden Link: https://lore.kernel.org/r/20221111170632.77622-2-imbrenda@linux.ibm.com Message-Id: <20221111170632.77622-2-imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank

KVM: s390: pv: sort out physical vs virtual pointers usage

2022-10-26T12:27:41Z

Fix virtual vs physical address confusion (which currently are the same). Signed-off-by: Nico Boehr Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20221020143159.294605-6-nrb@linux.ibm.com Message-Id: <20221020143159.294605-6-nrb@linux.ibm.com> Signed-off-by: Janosch Frank

KVM: s390: sida: sort out physical vs virtual pointers usage

2022-10-26T12:27:41Z

All callers of the sida_origin() macro actually expected a virtual address, so rename it to sida_addr() and hand out a virtual address. At some places, the macro wasn't used, potentially creating problems if the sida size ever becomes nonzero (not currently the case), so let's start using it everywhere now while at it. Signed-off-by: Nico Boehr Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20221020143159.294605-5-nrb@linux.ibm.com Message-Id: <20221020143159.294605-5-nrb@linux.ibm.com> Signed-off-by: Janosch Frank

KVM: s390: pv: destroy the configuration before its memory

2022-07-19T12:06:56Z

Move the Destroy Secure Configuration UVC before the loop to destroy the memory. If the protected VM has memory, it will be cleaned up and made accessible by the Destroy Secure Configuration UVC. The struct page for the relevant pages will still have the protected bit set, so the loop is still needed to clean that up. Switching the order of those two operations does not change the outcome, but it is significantly faster. Signed-off-by: Claudio Imbrenda Reviewed-by: Nico Boehr Reviewed-by: Janosch Frank Link: https://lore.kernel.org/r/20220628135619.32410-13-imbrenda@linux.ibm.com Message-Id: <20220628135619.32410-13-imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank

KVM: s390: pv: refactoring of kvm_s390_pv_deinit_vm

2022-07-19T12:06:56Z

Refactor kvm_s390_pv_deinit_vm to improve readability and simplify the improvements that are coming in subsequent patches. No functional change intended. Signed-off-by: Claudio Imbrenda Reviewed-by: Janosch Frank Link: https://lore.kernel.org/r/20220628135619.32410-12-imbrenda@linux.ibm.com Message-Id: <20220628135619.32410-12-imbrenda@linux.ibm.com> [frankja@linux.ibm.com: Dropped commit message line regarding review] Signed-off-by: Janosch Frank

KVM: s390: pv: add mmu_notifier

2022-07-19T12:05:57Z

Add an mmu_notifier for protected VMs. The callback function is triggered when the mm is torn down, and will attempt to convert all protected vCPUs to non-protected. This allows the mm teardown to use the destroy page UVC instead of export. Also make KVM select CONFIG_MMU_NOTIFIER, needed to use mmu_notifiers. Signed-off-by: Claudio Imbrenda Acked-by: Janosch Frank Reviewed-by: Nico Boehr Link: https://lore.kernel.org/r/20220628135619.32410-10-imbrenda@linux.ibm.com Message-Id: <20220628135619.32410-10-imbrenda@linux.ibm.com> [frankja@linux.ibm.com: Conflict resolution for mmu_notifier.h include and struct kvm_s390_pv] Signed-off-by: Janosch Frank

KVM: s390: pv: clear the state without memset

2022-07-13T14:42:11Z

Do not use memset to clean the whole struct kvm_s390_pv; instead, explicitly clear the fields that need to be cleared. Upcoming patches will introduce new fields in the struct kvm_s390_pv that will not need to be cleared. Signed-off-by: Claudio Imbrenda Reviewed-by: Janosch Frank Link: https://lore.kernel.org/r/20220628135619.32410-8-imbrenda@linux.ibm.com Message-Id: <20220628135619.32410-8-imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank

KVM: s390: pv: usage counter instead of flag

2022-07-13T14:42:11Z

Use the new protected_count field as a counter instead of the old is_protected flag. This will be used in upcoming patches. Increment the counter when a secure configuration is created, and decrement it when it is destroyed. Previously the flag was set when the set secure parameters UVC was performed. Signed-off-by: Claudio Imbrenda Acked-by: Janosch Frank Link: https://lore.kernel.org/r/20220628135619.32410-6-imbrenda@linux.ibm.com Message-Id: <20220628135619.32410-6-imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank