lkml.org 
[lkml]   [2022]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v8 003/103] KVM: Refactor CPU compatibility check on module initialization
From

On 2022/8/8 6:00, isaku.yamahata@intel.com wrote:
> From: Isaku Yamahata <isaku.yamahata@intel.com>
>
> TDX module requires its initialization. It requires VMX to be enabled.
> Although there are several options of when to initialize it, the choice is
> the initialization time of the KVM kernel module. There is no usable
> arch-specific hook for the TDX module to utilize during the KVM kernel module
> initialization. The code doesn't enable/disable hardware (VMX in TDX case)
> during the kernel module initialization. Add a hook for enabling hardware,
> arch-specific initialization, and disabling hardware during KVM kernel
> module initialization to make a room for TDX module initialization. The
> current KVM enables hardware when the first VM is created and disables
> hardware when the last VM is destroyed. When no VM is running, hardware is
> disabled. To follow these semantics, the kernel module initialization needs
> to disable hardware. Opportunistically refactor the code to enable/disable
> hardware.
>
> Add hadware_enable_all() and hardware_disable_all() to kvm_init() and
> introduce a new arch-specific callback function,
> kvm_arch_post_hardware_enable_setup, for arch to do arch-specific
> initialization that requires hardware_enable_all(). Opportunistically,
> move kvm_arch_check_processor_compat() to to hardware_enabled_nolock().
> TDX module initialization code will go into
> kvm_arch_post_hardware_enable_setup().
>
> This patch reorders some function calls as below from (*) (**) (A) and (B)
> to (A) (B) and (*). Here (A) and (B) depends on (*), but not (**). By
> code inspection, only mips and VMX has the code of (*). No other
No other or other?


> arch has empty (*). So refactor mips and VMX and eliminate the
> necessity hook for (*) instead of adding an unused hook.
>
> Before this patch:
> - Arch module initialization
> - kvm_init()
> - kvm_arch_init()
> - kvm_arch_check_processor_compat() on each CPUs
> - post-arch-specific initialization -- (*): (A) and (B) depends on this
> - post-arch-specific initialization -- (**): no dependency to (A) and (B)
>
> - When creating/deleting the first/last VM
> - kvm_arch_hardware_enable() on each CPUs -- (A)
> - kvm_arch_hardware_disable() on each CPUs -- (B)
>
> After this patch:
> - Arch module initialization
> - kvm_init()
> - kvm_arch_init()
> - arch-specific initialization -- (*)
> - kvm_arch_check_processor_compat() on each CPUs
> - kvm_arch_hardware_enable() on each CPUs -- (A)


Maybe also put the new added kvm_arch_post_hardware_enable_setup here?
After all, this is the purpose of this patch.


> - kvm_arch_hardware_disable() on each CPUs -- (B)
> - post-arch-specific initialization -- (**)
>
> - When creating/deleting the first/last VM (no logic change)
> - kvm_arch_hardware_enable() on each CPUs -- (A)
> - kvm_arch_hardware_disable() on each CPUs -- (B)
>

\
 
 \ /
  Last update: 2022-08-09 09:16    [W:0.646 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site