Received-SPF: pass (google.com: domain of linux-kernel+bounces-62894-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 12 Feb 2024 18:57:49 -0800
In-Reply-To: <CABgObfaEz8zmdqy4QatCKKqjugMxW+AsnLDAg6PN+BX1QyV01A@mail.gmail.com>
Precedence: bulk
Mime-Version: 1.0
References: <cover.1705965634.git.isaku.yamahata@intel.com>
 <591420ca62f0a9ac2478c2715181201c23f8acf0.1705965635.git.isaku.yamahata@intel.com>
 <CABgObfaEz8zmdqy4QatCKKqjugMxW+AsnLDAg6PN+BX1QyV01A@mail.gmail.com>
Message-ID: <Zcrarct88veirZx7@google.com>
Subject: Re: [PATCH v18 032/121] KVM: x86/mmu: introduce config for PRIVATE
 KVM MMU
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: isaku.yamahata@intel.com, kvm@vger.kernel.org, 
	linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, erdemaktas@google.com, 
	Sagi Shahar <sagis@google.com>, Kai Huang <kai.huang@intel.com>, chen.bo@intel.com, 
	hang.yuan@intel.com, tina.zhang@intel.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 12, 2024, Paolo Bonzini wrote:
> On Tue, Jan 23, 2024 at 12:55=E2=80=AFAM <isaku.yamahata@intel.com> wrote=
:
> >
> > From: Isaku Yamahata <isaku.yamahata@intel.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.
>=20
> Better, just put this as:
>=20
> config KVM_MMU_PRIVATE
>     bool
>=20
> but also add a reverse dependency to KVM_INTEL:
>=20
> 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
>      ...
>=20
> 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_priva=
te
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 =3D 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 probabl=
y be
better off with a static_key, a la kvm_has_noapic_vcpu (though I'm *extreme=
ly*
skeptical that that adds any measurable benefit).