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. > > Do we want to lose those flexibilities? > > -- > Thanks, > -Kai > >
