Received-SPF: pass (google.com: domain of linux-kernel+bounces-171907-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240423165328.2853870-1-seanjc@google.com> <4a66f882-12bf-4a07-a80a-a1600e89a103@intel.com>
 <ZippEkpjrEsGh5mj@google.com> <7f3001de041334b5c196b5436680473786a21816.camel@intel.com>
 <ZivMkK5PJbCQXnw2@google.com> <514f75b3-a2c5-4e8f-a98a-1ec54acb10bc@intel.com>
 <Zi_DNaC4FIIr7bRP@google.com>
In-Reply-To: <Zi_DNaC4FIIr7bRP@google.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Tue, 7 May 2024 19:20:51 +0200
Message-ID: <CABgObfYvkT39Msd11uJMZMquOsvNKBa=Z548JQZGfOmCF=TPaA@mail.gmail.com>
Subject: Re: [PATCH 0/3] KVM: x86: Fix supported VM_TYPES caps
To: Sean Christopherson <seanjc@google.com>
Cc: Kai Huang <kai.huang@intel.com>, Xiaoyao Li <xiaoyao.li@intel.com>, 
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 29, 2024 at 5:56=E2=80=AFPM Sean Christopherson <seanjc@google.=
com> wrote:
> > Perhaps we can make the kvm.ko as a dummy module which only keeps the m=
odule
> > parameters for backward compatibility?
>
> Keeping parameters in a dummy kvm.ko would largely defeat the purpose of =
linking
> everything into vendor modules, i.e. would make it possible for the param=
eters to
> hold a stale value.

We have the following read-write params:

parm:           nx_huge_pages:bool
parm:           nx_huge_pages_recovery_ratio:uint
parm:           nx_huge_pages_recovery_period_ms:uint
parm:           flush_on_reuse:bool
parm:           ignore_msrs:bool
parm:           report_ignored_msrs:bool
parm:           min_timer_period_us:uint
parm:           tsc_tolerance_ppm:uint
parm:           lapic_timer_advance_ns:int
parm:           force_emulation_prefix:int
parm:           pi_inject_timer:bint
parm:           eager_page_split:bool
parm:           halt_poll_ns:uint
parm:           halt_poll_ns_grow:uint
parm:           halt_poll_ns_grow_start:uint
parm:           halt_poll_ns_shrink:uint

Vendor modules do not muck with them (the only one that is exported is
report_ignored_msrs for which permanency is obviously harmless).

And the following read-only params:

parm:           tdp_mmu:bool
parm:           mmio_caching:bool
parm:           kvmclock_periodic_sync:bool
parm:           vector_hashing:bool
parm:           enable_vmware_backdoor:bool
parm:           enable_pmu:bool
parm:           mitigate_smt_rsb:bool

The only really bad one is tdp_mmu, which can change depending on the
ept/npt parameters of kvm-intel/kvm-amd; everything else is okay to
have in a common module.

mitigate_smt_rsb could (should?) move to kvm-amd.ko if the modules
were unified with kvm.ko as a dummy one.

Paolo