Re: [PATCH v2 26/50] KVM: PPC: Move processor compatibility check to module init

Sean Christopherson writes: > Move KVM PPC's compatibility checks to their respective module_init() > hooks, there's no need to wait until KVM's common compat check, nor is > there a need to perform the check on every CPU (provided by common KVM's > hook), as the compatibility checks operate on

Re: [PATCH 32/44] KVM: x86: Unify pr_fmt to use module name for all KVM modules

On Wed, 2022-11-30 at 23:02 +, Sean Christopherson wrote: > On Thu, Nov 10, 2022, Sean Christopherson wrote: > > On Thu, Nov 10, 2022, Robert Hoo wrote: > > > After this patch set, still find some printk()s left in > > > arch/x86/kvm/*, > > > consider clean all of them up? > > > > Hmm, yeah,

Re: [PATCH 2/4] KVM: arm64: Don't serialize if the access flag isn't set

On Wed, Nov 30, 2022 at 08:21:17AM +, Marc Zyngier wrote: > On Wed, 30 Nov 2022 01:23:20 +, > Ricardo Koller wrote: > > > > On Tue, Nov 29, 2022 at 09:15:21PM +, Oliver Upton wrote: > > > Hi Ricardo, > > > > > > Thanks for having a look. > > > > > > On Tue, Nov 29, 2022 at

[PATCH v2 49/50] KVM: Opt out of generic hardware enabling on s390 and PPC

Allow architectures to opt out of the generic hardware enabling logic, and opt out on both s390 and PPC, which don't need to manually enable virtualization as it's always on (when available). In addition to letting s390 and PPC drop a bit of dead code, this will hopefully also allow ARM to clean

[PATCH v2 44/50] KVM: Drop kvm_count_lock and instead protect kvm_usage_count with kvm_lock

From: Isaku Yamahata Drop kvm_count_lock and instead protect kvm_usage_count with kvm_lock now that KVM hooks CPU hotplug during the ONLINE phase, which can sleep. Previously, KVM hooked the STARTING phase, which is not allowed to sleep and thus could not take kvm_lock (a mutex). This

[PATCH v2 46/50] KVM: Use a per-CPU variable to track which CPUs have enabled virtualization

Use a per-CPU variable instead of a shared bitmap to track which CPUs have successfully enabled virtualization hardware. Using a per-CPU bool avoids the need for an additional allocation, and arguably yields easier to read code. Using a bitmap would be advantageous if KVM used it to avoid

[PATCH v2 50/50] KVM: Clean up error labels in kvm_init()

Convert the last two "out" lables to "err" labels now that the dust has settled, i.e. now that there are no more planned changes to the order of things in kvm_init(). Use "err" instead of "out" as it's easier to describe what failed than it is to describe what needs to be unwound, e.g. if

[PATCH v2 48/50] KVM: Register syscore (suspend/resume) ops early in kvm_init()

Register the suspend/resume notifier hooks at the same time KVM registers its reboot notifier so that all the code in kvm_init() that deals with enabling/disabling hardware is bundled together. Opportunstically move KVM's implementations to reside near the reboot notifier code for the same

[PATCH v2 47/50] KVM: Make hardware_enable_failed a local variable in the "enable all" path

From: Isaku Yamahata Rework detecting hardware enabling errors to use a local variable in the "enable all" path to track whether or not enabling was successful across all CPUs. Using a global variable complicates paths that enable hardware only on the current CPU, e.g. kvm_resume() and

[PATCH v2 45/50] KVM: Remove on_each_cpu(hardware_disable_nolock) in kvm_exit()

From: Isaku Yamahata Drop the superfluous invocation of hardware_disable_nolock() during kvm_exit(), as it's nothing more than a glorified nop. KVM automatically disables hardware on all CPUs when the last VM is destroyed, and kvm_exit() cannot be called until the last VM goes away as the

[PATCH v2 43/50] KVM: Ensure CPU is stable during low level hardware enable/disable

Use the non-raw smp_processor_id() in the low hardware enable/disable helpers as KVM absolutely relies on the CPU being stable, e.g. KVM would end up with incorrect state if the task were migrated between accessing cpus_hardware_enabled and actually enabling/disabling hardware. Signed-off-by:

[PATCH v2 41/50] KVM: Rename and move CPUHP_AP_KVM_STARTING to ONLINE section

From: Chao Gao The CPU STARTING section doesn't allow callbacks to fail. Move KVM's hotplug callback to ONLINE section so that it can abort onlining a CPU in certain cases to avoid potentially breaking VMs running on existing CPUs. For example, when KVM fails to enable hardware virtualization on

[PATCH v2 40/50] KVM: x86: Do compatibility checks when onlining CPU

From: Chao Gao Do compatibility checks when enabling hardware to effectively add compatibility checks when onlining a CPU. Abort enabling, i.e. the online process, if the (hotplugged) CPU is incompatible with the known good setup. At init time, KVM does compatibility checks to ensure that all

[PATCH v2 42/50] KVM: Disable CPU hotplug during hardware enabling/disabling

From: Chao Gao Disable CPU hotplug when enabling/disabling hardware to prevent the corner case where if the following sequence occurs: 1. A hotplugged CPU marks itself online in cpu_online_mask 2. The hotplugged CPU enables interrupt before invoking KVM's ONLINE callback 3

[PATCH v2 37/50] KVM: VMX: Shuffle support checks and hardware enabling code around

Reorder code in vmx.c so that the VMX support check helpers reside above the hardware enabling helpers, which will allow KVM to perform support checks during hardware enabling (in a future patch). No functional change intended. Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/vmx.c |

[PATCH v2 39/50] KVM: x86: Move CPU compat checks hook to kvm_x86_ops (from kvm_x86_init_ops)

Move the .check_processor_compatibility() callback from kvm_x86_init_ops to kvm_x86_ops to allow a future patch to do compatibility checks during CPU hotplug. Do kvm_ops_update() before compat checks so that static_call() can be used during compat checks. Signed-off-by: Sean Christopherson ---

[PATCH v2 35/50] KVM: VMX: Use current CPU's info to perform "disabled by BIOS?" checks

Use this_cpu_has() instead of boot_cpu_has() to perform the effective "disabled by BIOS?" checks for VMX. This will allow consolidating code between vmx_disabled_by_bios() and vmx_check_processor_compat(). Checking the boot CPU isn't a strict requirement as any divergence in VMX enabling between

[PATCH v2 38/50] KVM: SVM: Check for SVM support in CPU compatibility checks

Check that SVM is supported and enabled in the processor compatibility checks. SVM already checks for support during hardware enabling, i.e. this doesn't really add new functionality. The net effect is that KVM will refuse to load if a CPU doesn't have SVM fully enabled, as opposed to failing

[PATCH v2 34/50] KVM: x86: Unify pr_fmt to use module name for all KVM modules

Define pr_fmt using KBUILD_MODNAME for all KVM x86 code so that printks use consistent formatting across common x86, Intel, and AMD code. In addition to providing consistent print formatting, using KBUILD_MODNAME, e.g. kvm_amd and kvm_intel, allows referencing SVM and VMX (and SEV and SGX and

[PATCH v2 36/50] KVM: x86: Do VMX/SVM support checks directly in vendor code

Do basic VMX/SVM support checks directly in vendor code instead of implementing them via kvm_x86_ops hooks. Beyond the superficial benefit of providing common messages, which isn't even clearly a net positive since vendor code can provide more precise/detailed messages, there's zero advantage to

[PATCH v2 31/50] KVM: x86: Do CPU compatibility checks in x86 code

Move the CPU compatibility checks to pure x86 code, i.e. drop x86's use of the common kvm_x86_check_cpu_compat() arch hook. x86 is the only architecture that "needs" to do per-CPU compatibility checks, moving the logic to x86 will allow dropping the common code, and will also give x86 more

[PATCH v2 28/50] KVM: s390: Mark __kvm_s390_init() and its descendants as __init

Tag __kvm_s390_init() and its unique helpers as __init. These functions are only ever called during module_init(), but could not be tagged accordingly while they were invoked from the common kvm_arch_init(), which is not __init because of x86. Signed-off-by: Sean Christopherson Reviewed-by:

[PATCH v2 32/50] KVM: Drop kvm_arch_check_processor_compat() hook

Drop kvm_arch_check_processor_compat() and its support code now that all architecture implementations are nops. Signed-off-by: Sean Christopherson Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Eric Farman # s390 Acked-by: Anup Patel --- arch/arm64/kvm/arm.c | 7 +--

[PATCH v2 33/50] KVM: x86: Use KBUILD_MODNAME to specify vendor module name

Use KBUILD_MODNAME to specify the vendor module name instead of manually writing out the name to make it a bit more obvious that the name isn't completely arbitrary. A future patch will also use KBUILD_MODNAME to define pr_fmt, at which point using KBUILD_MODNAME for kvm_x86_ops.name further

[PATCH v2 30/50] KVM: VMX: Make VMCS configuration/capabilities structs read-only after init

Tag vmcs_config and vmx_capability structs as __init, the canonical configuration is generated during hardware_setup() and must never be modified after that point. Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/capabilities.h | 4 ++-- arch/x86/kvm/vmx/vmx.c | 4 ++-- 2 files

[PATCH v2 29/50] KVM: Drop kvm_arch_{init,exit}() hooks

Drop kvm_arch_init() and kvm_arch_exit() now that all implementations are nops. No functional change intended. Signed-off-by: Sean Christopherson Reviewed-by: Eric Farman # s390 Reviewed-by: Philippe Mathieu-Daudé Acked-by: Anup Patel --- arch/arm64/kvm/arm.c| 11 ---

[PATCH v2 24/50] KVM: RISC-V: Do arch init directly in riscv_kvm_init()

Fold the guts of kvm_arch_init() into riscv_kvm_init() instead of bouncing through kvm_init()=>kvm_arch_init(). Functionally, this is a glorified nop as invoking kvm_arch_init() is the very first action performed by kvm_init(). Moving setup to riscv_kvm_init(), which is tagged __init, will allow

[PATCH v2 27/50] KVM: s390: Do s390 specific init without bouncing through kvm_init()

Move the guts of kvm_arch_init() into a new helper, __kvm_s390_init(), and invoke the new helper directly from kvm_s390_init() instead of bouncing through kvm_init(). Invoking kvm_arch_init() is the very first action performed by kvm_init(), i.e. this is a glorified nop. Moving setup to

[PATCH v2 26/50] KVM: PPC: Move processor compatibility check to module init

Move KVM PPC's compatibility checks to their respective module_init() hooks, there's no need to wait until KVM's common compat check, nor is there a need to perform the check on every CPU (provided by common KVM's hook), as the compatibility checks operate on global data.

[PATCH v2 25/50] KVM: RISC-V: Tag init functions and data with __init, __ro_after_init

Now that KVM setup is handled directly in riscv_kvm_init(), tag functions and data that are used/set only during init with __init/__ro_after_init. Signed-off-by: Sean Christopherson Acked-by: Anup Patel --- arch/riscv/include/asm/kvm_host.h | 6 +++--- arch/riscv/kvm/mmu.c | 12

[PATCH v2 23/50] KVM: MIPS: Register die notifier prior to kvm_init()

Call kvm_init() only after _all_ setup is complete, as kvm_init() exposes /dev/kvm to userspace and thus allows userspace to create VMs (and call other ioctls). Signed-off-by: Sean Christopherson Reviewed-by: Philippe Mathieu-Daudé --- arch/mips/kvm/mips.c | 9 + 1 file changed, 5

[PATCH v2 20/50] KVM: arm64: Mark kvm_arm_init() and its unique descendants as __init

Tag kvm_arm_init() and its unique helper as __init, and tag data that is only ever modified under the kvm_arm_init() umbrella as read-only after init. Opportunistically name the boolean param in kvm_timer_hyp_init()'s prototype to match its definition. Signed-off-by: Sean Christopherson ---

[PATCH v2 21/50] KVM: MIPS: Hardcode callbacks to hardware virtualization extensions

Now that KVM no longer supports trap-and-emulate (see commit 45c7e8af4a5e "MIPS: Remove KVM_TE support"), hardcode the MIPS callbacks to the virtualization callbacks. Harcoding the callbacks eliminates the technically-unnecessary check on non-NULL kvm_mips_callbacks in kvm_arch_init(). MIPS has

[PATCH v2 22/50] KVM: MIPS: Setup VZ emulation? directly from kvm_mips_init()

Invoke kvm_mips_emulation_init() directly from kvm_mips_init() instead of bouncing through kvm_init()=>kvm_arch_init(). Functionally, this is a glorified nop as invoking kvm_arch_init() is the very first action performed by kvm_init(). Emptying kvm_arch_init() will allow dropping the hook

[PATCH v2 19/50] KVM: arm64: Do arm/arch initialization without bouncing through kvm_init()

Do arm/arch specific initialization directly in arm's module_init(), now called kvm_arm_init(), instead of bouncing through kvm_init() to reach kvm_arch_init(). Invoking kvm_arch_init() is the very first action performed by kvm_init(), so from a initialization perspective this is a glorified nop.

[PATCH v2 16/50] KVM: arm64: Simplify the CPUHP logic

From: Marc Zyngier For a number of historical reasons, the KVM/arm64 hotplug setup is pretty complicated, and we have two extra CPUHP notifiers for vGIC and timers. It looks pretty pointless, and gets in the way of further changes. So let's just expose some helpers that can be called from the

[PATCH v2 15/50] KVM: x86: Serialize vendor module initialization (hardware setup)

Acquire a new mutex, vendor_module_lock, in kvm_x86_vendor_init() while doing hardware setup to ensure that concurrent calls are fully serialized. KVM rejects attempts to load vendor modules if a different module has already been loaded, but doesn't handle the case where multiple vendor modules

[PATCH v2 18/50] KVM: arm64: Unregister perf callbacks if hypervisor finalization fails

Undo everything done by init_subsystems() if a later initialization step fails, i.e. unregister perf callbacks in addition to unregistering the power management notifier. Fixes: bfa79a805454 ("KVM: arm64: Elevate hypervisor mappings creation at EL2") Signed-off-by: Sean Christopherson ---

[PATCH v2 17/50] KVM: arm64: Free hypervisor allocations if vector slot init fails

Teardown hypervisor mode if vector slot setup fails in order to avoid leaking any allocations done by init_hyp_mode(). Fixes: b881cdce77b4 ("KVM: arm64: Allocate hyp vectors statically") Signed-off-by: Sean Christopherson --- arch/arm64/kvm/arm.c | 15 --- 1 file changed, 8

[PATCH v2 14/50] KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace

Call kvm_init() only after _all_ setup is complete, as kvm_init() exposes /dev/kvm to userspace and thus allows userspace to create VMs (and call other ioctls). E.g. KVM will encounter a NULL pointer when attempting to add a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able to

[PATCH v2 12/50] KVM: VMX: Move Hyper-V eVMCS initialization to helper

Move Hyper-V's eVMCS initialization to a dedicated helper to clean up vmx_init(), and add a comment to call out that the Hyper-V init code doesn't need to be unwound if vmx_init() ultimately fails. No functional change intended. Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/vmx.c |

[PATCH v2 11/50] KVM: VMX: Don't bother disabling eVMCS static key on module exit

Don't disable the eVMCS static key on module exit, kvm_intel.ko owns the key so there can't possibly be users after the kvm_intel.ko is unloaded, at least not without much bigger issues. Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/vmx.c | 4 1 file changed, 4 deletions(-) diff

[PATCH v2 13/50] KVM: x86: Move guts of kvm_arch_init() to standalone helper

Move the guts of kvm_arch_init() to a new helper, kvm_x86_vendor_init(), so that VMX can do _all_ arch and vendor initialization before calling kvm_init(). Calling kvm_init() must be the _very_ last step during init, as kvm_init() exposes /dev/kvm to userspace, i.e. allows creating VMs. No

[PATCH v2 10/50] KVM: VMX: Reset eVMCS controls in VP assist page during hardware disabling

Reset the eVMCS controls in the per-CPU VP assist page during hardware disabling instead of waiting until kvm-intel's module exit. The controls are activated if and only if KVM creates a VM, i.e. don't need to be reset if hardware is never enabled. Doing the reset during hardware disabling will

[PATCH v2 09/50] KVM: Drop arch hardware (un)setup hooks

Drop kvm_arch_hardware_setup() and kvm_arch_hardware_unsetup() now that all implementations are nops. No functional change intended. Signed-off-by: Sean Christopherson Reviewed-by: Eric Farman # s390 Acked-by: Anup Patel --- arch/arm64/include/asm/kvm_host.h | 1 - arch/arm64/kvm/arm.c

[PATCH v2 07/50] KVM: x86: Do timer initialization after XCR0 configuration

Move kvm_arch_init()'s call to kvm_timer_init() down a few lines below the XCR0 configuration code. A future patch will move hardware setup into kvm_arch_init() and slot in vendor hardware setup before the call to kvm_timer_init() so that timer initialization (among other stuff) doesn't need to

[PATCH v2 08/50] KVM: x86: Move hardware setup/unsetup to init/exit

Now that kvm_arch_hardware_setup() is called immediately after kvm_arch_init(), fold the guts of kvm_arch_hardware_(un)setup() into kvm_arch_{init,exit}() as a step towards dropping one of the hooks. To avoid having to unwind various setup, e.g registration of several notifiers, slot in the

[PATCH v2 05/50] KVM: s390: Unwind kvm_arch_init() piece-by-piece() if a step fails

In preparation for folding kvm_arch_hardware_setup() into kvm_arch_init(), unwind initialization one step at a time instead of simply calling kvm_arch_exit(). Using kvm_arch_exit() regardless of which initialization step failed relies on all affected state playing nice with being undone even if

[PATCH v2 03/50] KVM: Allocate cpus_hardware_enabled after arch hardware setup

Allocate cpus_hardware_enabled after arch hardware setup so that arch "init" and "hardware setup" are called back-to-back and thus can be combined in a future patch. cpus_hardware_enabled is never used before kvm_create_vm(), i.e. doesn't have a dependency with hardware setup and only needs to be

[PATCH v2 06/50] KVM: s390: Move hardware setup/unsetup to init/exit

Now that kvm_arch_hardware_setup() is called immediately after kvm_arch_init(), fold the guts of kvm_arch_hardware_(un)setup() into kvm_arch_{init,exit}() as a step towards dropping one of the hooks. No functional change intended. Signed-off-by: Sean Christopherson Reviewed-by: Eric Farman ---

[PATCH v2 04/50] KVM: Teardown VFIO ops earlier in kvm_exit()

Move the call to kvm_vfio_ops_exit() further up kvm_exit() to try and bring some amount of symmetry to the setup order in kvm_init(), and more importantly so that the arch hooks are invoked dead last by kvm_exit(). This will allow arch code to move away from the arch hooks without any change in

[PATCH v2 02/50] KVM: Initialize IRQ FD after arch hardware setup

Move initialization of KVM's IRQ FD workqueue below arch hardware setup as a step towards consolidating arch "init" and "hardware setup", and eventually towards dropping the hooks entirely. There is no dependency on the workqueue being created before hardware setup, the workqueue is used only

[PATCH v2 00/50] KVM: Rework kvm_init() and hardware enabling

The main theme of this series is to kill off kvm_arch_init(), kvm_arch_hardware_(un)setup(), and kvm_arch_check_processor_compat(), which all originated in x86 code from way back when, and needlessly complicate both common KVM code and architecture code. E.g. many architectures don't mark

[PATCH v2 01/50] KVM: Register /dev/kvm as the _very_ last thing during initialization

Register /dev/kvm, i.e. expose KVM to userspace, only after all other setup has completed. Once /dev/kvm is exposed, userspace can start invoking KVM ioctls, creating VMs, etc... If userspace creates a VM before KVM is done with its configuration, bad things may happen, e.g. KVM will fail to

Re: [PATCH 32/44] KVM: x86: Unify pr_fmt to use module name for all KVM modules

On Thu, Nov 10, 2022, Sean Christopherson wrote: > On Thu, Nov 10, 2022, Robert Hoo wrote: > > After this patch set, still find some printk()s left in arch/x86/kvm/*, > > consider clean all of them up? > > Hmm, yeah, I suppose at this point it makes sense to tack on a patch to clean > them up.

Re: [PATCH 0/4] KVM: arm64: Parallel access faults

On Tue, 29 Nov 2022 19:19:42 +, Oliver Upton wrote: > > When I implemented the parallel faults series I was mostly focused on > improving the performance of 8.1+ implementations which bring us > FEAT_HAFDBS. In so doing, I failed to put access faults on the read side > of the MMU lock. > >

Re: [PATCH 2/4] KVM: arm64: Don't serialize if the access flag isn't set

On Wed, 30 Nov 2022 01:23:20 +, Ricardo Koller wrote: > > On Tue, Nov 29, 2022 at 09:15:21PM +, Oliver Upton wrote: > > Hi Ricardo, > > > > Thanks for having a look. > > > > On Tue, Nov 29, 2022 at 12:52:12PM -0800, Ricardo Koller wrote: > > > On Tue, Nov 29, 2022 at 07:19:44PM +,