On Wed, Aug 17, 2022 at 9:53 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 8/17/22 18:49, David Matlack wrote: > > On Wed, Aug 17, 2022 at 3:05 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > >> > >> On 8/16/22 01:01, David Matlack wrote: > >>> Delete the module parameter tdp_mmu and force KVM to always use the TDP > >>> MMU when TDP hardware support is enabled. > >>> > >>> 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. > >>> > >>> Dropping the ability to disable the TDP MMU reduces the number of > >>> possible configurations that need to be tested to validate KVM (i.e. no > >>> need to test with tdp_mmu=N), and simplifies the code. > >> > >> The snag is that the shadow MMU is only supported on 64-bit systems; > >> testing tdp_mmu=0 is not a full replacement for booting up a 32-bit > >> distro, but it's easier (I do 32-bit testing only with nested virt). > > > > Ah, I did forget about 32-bit systems :(. Do Intel or AMD CPUs support > > TDP in 32-bit mode? > > Both do. Intel theoretically on some 32-bit processors that were > actually sold, too. > > >> Personally I'd have no problem restricting KVM to x86-64 but I know > >> people would complain. > > > > As a middle-ground we could stop supporting TDP on 32-bit > > systems. 32-bit KVM would continue working but just with shadow > > paging. > > The main problem is, shadow paging is awfully slow due to Meltdown > mitigations these days. I would start with the read-only parameter and > then see whether there's more low-hanging fruit (e.g. make fast page > fault TDP MMU-only). Will do, thanks for the feedback. > > Paolo > > >> What about making the tdp_mmu module parameter read-only, so that at > >> least kvm->arch.tdp_mmu_enabled can be replaced by a global variable? > >> > >> Paolo > >> > > >
