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
