On Mon, Apr 11, 2022, Ben Gardon wrote: > @@ -6079,6 +6080,11 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, > } > mutex_unlock(&kvm->lock); > break; > + case KVM_CAP_VM_DISABLE_NX_HUGE_PAGES: > + kvm->arch.disable_nx_huge_pages = true; It's probably worth requiring cap->args[0] to be zero, KVM has been burned too many times by lack of extensibility. > + kvm_update_nx_huge_pages(kvm); Is there actually a use case to do this while the VM is running? Given that this is a one-way control, i.e. userspace can't re-enable the mitigation, me thinks the answer is no. And logically, I don't see why userspace would suddenly decide to trust the guest at some random point in time. So, require this to be done before vCPUs are created, then there's no need to zap SPTEs because there can't be any SPTEs to zap. Then the previous patch also goes away. Or to be really draconian, disallow the cap if memslots have been created, though I think created_vcpus will be sufficient now and in the future. We can always lift the restriction if someone has a use case for toggling this while the VM is running, but we can't do the reverse.
