Re: [PATCH v4 0/6] KVM: MMU: performance tweaks for heavy CR0.WP users

[Greg KH <greg@kroah.com>]

On Sat, Mar 25, 2023 at 12:39:59PM +0100, Mathias Krause wrote:
> On 23.03.23 23:50, Sean Christopherson wrote:
> > On Wed, 22 Mar 2023 02:37:25 +0100, Mathias Krause wrote:
> >> v3: https://lore.kernel.org/kvm/20230201194604.11135-1-minipli@grsecurity.net/
> >>
> >> This series is the fourth iteration of resurrecting the missing pieces of
> >> Paolo's previous attempt[1] to avoid needless MMU roots unloading.
> >>
> >> It's incorporating Sean's feedback to v3 and rebased on top of
> >> kvm-x86/next, namely commit d8708b80fa0e ("KVM: Change return type of
> >> kvm_arch_vm_ioctl() to "int"").
> >>
> >> [...]
> > 
> > Applied 1 and 5 to kvm-x86 mmu, and the rest to kvm-x86 misc, thanks!
> > 
> > [1/6] KVM: x86/mmu: Avoid indirect call for get_cr3
> >       https://github.com/kvm-x86/linux/commit/2fdcc1b32418
> > [2/6] KVM: x86: Do not unload MMU roots when only toggling CR0.WP with TDP enabled
> >       https://github.com/kvm-x86/linux/commit/01b31714bd90
> > [3/6] KVM: x86: Ignore CR0.WP toggles in non-paging mode
> >       https://github.com/kvm-x86/linux/commit/e40bcf9f3a18
> > [4/6] KVM: x86: Make use of kvm_read_cr*_bits() when testing bits
> >       https://github.com/kvm-x86/linux/commit/74cdc836919b
> > [5/6] KVM: x86/mmu: Fix comment typo
> >       https://github.com/kvm-x86/linux/commit/50f13998451e
> > [6/6] KVM: VMX: Make CR0.WP a guest owned bit
> >       https://github.com/kvm-x86/linux/commit/fb509f76acc8
> 
> Thanks a lot, Sean!
> 
> As this is a huge performance fix for us, we'd like to get it integrated
> into current stable kernels as well -- not without having the changes
> get some wider testing, of course, i.e. not before they end up in a
> non-rc version released by Linus. But I already did a backport to 5.4 to
> get a feeling how hard it would be and for the impact it has on older
> kernels.
> 
> Using the 'ssdd 10 50000' test I used before, I get promising results
> there as well. Without the patches it takes 9.31s, while with them we're
> down to 4.64s. Taking into account that this is the runtime of a
> workload in a VM that gets cut in half, I hope this qualifies as stable
> material, as it's a huge performance fix.
> 
> Greg, what's your opinion on it? Original series here:
> https://lore.kernel.org/kvm/20230322013731.102955-1-minipli@grsecurity.net/

I'll leave the judgement call up to the KVM maintainers, as they are the
ones that need to ack any KVM patch added to stable trees.

thanks,

greg k-h