[v18,032/121] KVM: x86/mmu: introduce config for PRIVATE KVM MMU

Commit Message

Isaku Yamahata Jan. 22, 2024, 11:53 p.m. UTC

From: Isaku Yamahata <[e-mail]>

To keep the case of non TDX intact, introduce a new config option for
private KVM MMU support.  At the moment, this is synonym for
CONFIG_INTEL_TDX_HOST && CONFIG_KVM_INTEL.  The config makes it clear
that the config is only for x86 KVM MMU.

Signed-off-by: Isaku Yamahata <[e-mail]>
---
 arch/x86/kvm/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Paolo Bonzini Feb. 12, 2024, 2:18 p.m. UTC | #1

On Tue, Jan 23, 2024 at 12:55 AM <[e-mail]> wrote:
>
> From: Isaku Yamahata <[e-mail]>
>
> To keep the case of non TDX intact, introduce a new config option for
> private KVM MMU support.  At the moment, this is synonym for
> CONFIG_INTEL_TDX_HOST && CONFIG_KVM_INTEL.  The config makes it clear
> that the config is only for x86 KVM MMU.

Better, just put this as:

config KVM_MMU_PRIVATE
    bool

but also add a reverse dependency to KVM_INTEL:

config KVM_INTEL
     tristate "KVM for Intel (and compatible) processors support"
     depends on KVM && IA32_FEAT_CTL
     select KVM_MMU_PRIVATE if INTEL_TDX_HOST
     ...

This matches the usage of kvm-intel-$(INTEL_TDX_HOST) in the Makefile.

Paolo

> Signed-off-by: Isaku Yamahata <[e-mail]>
> ---
>  arch/x86/kvm/Kconfig | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index cd3de7b9a665..fa00abb9ab39 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -189,4 +189,8 @@ config KVM_MAX_NR_VCPUS
>           the memory footprint of each KVM guest, regardless of how many vCPUs are
>           created for a given VM.
>
> +config KVM_MMU_PRIVATE
> +       def_bool y
> +       depends on INTEL_TDX_HOST && KVM_INTEL
> +
>  endif # VIRTUALIZATION
> --
> 2.25.1
>

Sean Christopherson Feb. 13, 2024, 2:57 a.m. UTC | #2

On Mon, Feb 12, 2024, Paolo Bonzini wrote:
> On Tue, Jan 23, 2024 at 12:55 AM <[e-mail]> wrote:
> >
> > From: Isaku Yamahata <[e-mail]>
> >
> > To keep the case of non TDX intact, introduce a new config option for
> > private KVM MMU support.  At the moment, this is synonym for
> > CONFIG_INTEL_TDX_HOST && CONFIG_KVM_INTEL.  The config makes it clear
> > that the config is only for x86 KVM MMU.
> 
> Better, just put this as:
> 
> config KVM_MMU_PRIVATE
>     bool
> 
> but also add a reverse dependency to KVM_INTEL:
> 
> config KVM_INTEL
>      tristate "KVM for Intel (and compatible) processors support"
>      depends on KVM && IA32_FEAT_CTL
>      select KVM_MMU_PRIVATE if INTEL_TDX_HOST
>      ...
> 
> This matches the usage of kvm-intel-$(INTEL_TDX_HOST) in the Makefile.

But why even bother with a Kconfig in the first place?  Saving the is_private
bit in the role adds no value whatsoever.  In fact, it's probably a big net
negative because it necessitates this ugly code:

	if (private)
		kvm_mmu_page_role_set_private(&role);

which really should just be

	role.private = private;

Ditto for kvm_mmu_page.private_spt.

The only thing that even so much as approaches being a hot path is
kvm_gfn_shared_mask(), and if that needs to be optimized, then we'd probably be
better off with a static_key, a la kvm_has_noapic_vcpu (though I'm *extremely*
skeptical that that adds any measurable benefit).

Paolo Bonzini Feb. 13, 2024, 4:47 p.m. UTC | #3

On Tue, Feb 13, 2024 at 3:57 AM Sean Christopherson <[e-mail]> wrote:
> The only thing that even so much as approaches being a hot path is
> kvm_gfn_shared_mask(), and if that needs to be optimized, then we'd probably be
> better off with a static_key, a la kvm_has_noapic_vcpu (though I'm *extremely*
> skeptical that that adds any measurable benefit).

I'm okay with killing it altogether.

Paolo

Isaku Yamahata Feb. 26, 2024, 5:48 p.m. UTC | #4

On Tue, Feb 13, 2024 at 05:47:43PM +0100,
Paolo Bonzini <[e-mail]> wrote:

> On Tue, Feb 13, 2024 at 3:57 AM Sean Christopherson <[e-mail]> wrote:
> > The only thing that even so much as approaches being a hot path is
> > kvm_gfn_shared_mask(), and if that needs to be optimized, then we'd probably be
> > better off with a static_key, a la kvm_has_noapic_vcpu (though I'm *extremely*
> > skeptical that that adds any measurable benefit).
> 
> I'm okay with killing it altogether.

I eliminated this config.

Patch

diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index cd3de7b9a665..fa00abb9ab39 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -189,4 +189,8 @@  config KVM_MAX_NR_VCPUS
 	  the memory footprint of each KVM guest, regardless of how many vCPUs are
 	  created for a given VM.
 
+config KVM_MMU_PRIVATE
+	def_bool y
+	depends on INTEL_TDX_HOST && KVM_INTEL
+
 endif # VIRTUALIZATION