Re: [PATCH 0/3] KVM: x86: Fix supported VM_TYPES caps

[Paolo Bonzini]

On Mon, Apr 29, 2024 at 5:56 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > Perhaps we can make the kvm.ko as a dummy module which only keeps the module
> > 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 parameters 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