On Wed, 2022-08-17 at 09:42 -0700, David Matlack wrote: > On Wed, Aug 17, 2022 at 3:01 AM Huang, Kai <kai.huang@xxxxxxxxx> wrote: > > > > 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. > > I am proposing that KVM stops supporting this use-case, so testing it > would no longer be necessary. However, based on Paolo's reply there > might be a snag with 32-bit systems. > > > Or when there's some problem with TDP > > MMU code, we can easily switch to use legacy MMU. > > Who is "we" in this context? For cloud providers, switching a customer > VM from the TDP MMU back to the shadow MMU to fix an issue is not > feasible. The shadow MMU uses more memory and has worse performance > for larger VMs, i.e. switching comes with significant downsides that > are unlikely to be lower risk than simply rolling out a fix for the > TDP MMU. > > Also, over time, the TDP MMU will be less and less likely to have bugs > than the shadow MMU for TDP-enabled use-cases. e.g. The TDP MMU has > been default enabled since 5.15, so it has likely received > significantly more test cycles than the shadow MMU in the past 5 > releases. "We" means normal KVM patch developers. Yes I agree "switching to use legacy MMU" isn't a good argument from cloud providers' point of view. -- Thanks, -Kai
