On Mon, Feb 12, 2024, Paolo Bonzini wrote: > On Tue, Jan 23, 2024 at 12:55 AM <isaku.yamahata@xxxxxxxxx> wrote: > > > > From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx> > > > > 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).
