[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zcrarct88veirZx7@google.com>
Date: Mon, 12 Feb 2024 18:57:49 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: isaku.yamahata@...el.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, isaku.yamahata@...il.com, erdemaktas@...gle.com,
Sagi Shahar <sagis@...gle.com>, Kai Huang <kai.huang@...el.com>, chen.bo@...el.com,
hang.yuan@...el.com, tina.zhang@...el.com
Subject: Re: [PATCH v18 032/121] KVM: x86/mmu: introduce config for PRIVATE
KVM MMU
On Mon, Feb 12, 2024, Paolo Bonzini wrote:
> On Tue, Jan 23, 2024 at 12:55 AM <isaku.yamahata@...el.com> wrote:
> >
> > From: Isaku Yamahata <isaku.yamahata@...el.com>
> >
> > 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).
Powered by blists - more mailing lists