On Tue, 2022-08-16 at 09:30 -0700, David Matlack wrote: > On Tue, Aug 16, 2022 at 1:17 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > On Mon, Aug 15, 2022 at 04:01:01PM -0700, David Matlack wrote: > > > Patch 1 deletes the module parameter tdp_mmu and forces KVM to always > > > use the TDP MMU when TDP hardware support is enabled. The rest of the > > > patches are related cleanups that follow (although the kvm_faultin_pfn() > > > cleanups at the end are only tangentially related at best). > > > > > > The TDP MMU was introduced in 5.10 and has been enabled by default since > > > 5.15. At this point there are no known functionality gaps between the > > > TDP MMU and the shadow MMU, and the TDP MMU uses less memory and scales > > > better with the number of vCPUs. In other words, there is no good reason > > > to disable the TDP MMU. > > > > Then how are you going to test the shadow mmu code -- which I assume is > > still relevant for the platforms that don't have this hardware support > > you speak of? > > TDP hardware support can still be disabled with module parameters > (kvm_intel.ept=N and kvm_amd.npt=N). > > The tdp_mmu module parameter only controls whether KVM uses the TDP > MMU or shadow MMU *when TDP hardware is enabled*. With the tdp_mmu module parameter, when we develop some code, we can at least easily test legacy MMU code (that it is still working) when *TDP hardware is enabled* by turning the parameter off. Or when there's some problem with TDP MMU code, we can easily switch to use legacy MMU. Do we want to lose those flexibilities? -- Thanks, -Kai
