From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 496EAC433EF for ; Tue, 12 Apr 2022 17:54:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358561AbiDLR4l (ORCPT ); Tue, 12 Apr 2022 13:56:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237885AbiDLR4h (ORCPT ); Tue, 12 Apr 2022 13:56:37 -0400 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 291AF6466 for ; Tue, 12 Apr 2022 10:54:19 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id a21so3230275pfv.10 for ; Tue, 12 Apr 2022 10:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=g/wkfqACAO1R6swGFiX5nmXcMTqZOKO9AQAJHkwa6Yw=; b=Wyi6GlmOv6SCb15h1hHMmawDej03rLQGj8tm+MM1gNExlxevz5zy3nG6NqtSX5dMLY o0GPLv/gNUI+uypOTtJ4v3mkbxiAaj0hIe2FpOhQ5v33iFzbWz9bCXoMYDiD0+rv8inD 7zwE5VbVWzq5NBIAQ5hvXRZombD21rM4yBf+AzpcXtxheWJqC1iQTgbIYC/XamQQW3ci IX+t4jSob5vv4PPadlRhsGh9Tt3R3ViEDqgerLcGMx5v/bUjnUb/t6rzh77S0LGliyS2 HEVvhKOhWQ/t9hWCQLhtV8AjRYtmixTBfhHNGJQi8nuDqOkGPU7zB92m+4DT9x6UPkCD UGkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=g/wkfqACAO1R6swGFiX5nmXcMTqZOKO9AQAJHkwa6Yw=; b=jycLXbtSI2sPF9H5TT94VI5yBZJim33utgXhA72uz5QO/IpIJdcskSJio1qCtQtms/ K+IgybWgkvbV+d5qI/Efk3cKXfcbFPx2kwI5n3oaxtOOQPNIXmU9Im5/VsO3ZW3Vt7LQ 69nO1PavQvBs1RgpfLzprLpol0BuvAeDppsQ/yOulxgNE6v8ieHCF5Ksaz7mtXQcymVT HhegRRGKwT3xk3yidRgJvQPYWblZo2ftyoXLPcg3hbUpcKAelUfXZ7RSVAZSjFPjHnEQ DRwmi8MAfVDSE7i+pVmJDR1BeTHka9j+dAg71jbhLRTaD1d5/o79ZhzI7rjk2ppxgamm eqNA== X-Gm-Message-State: AOAM531Ej63opxN7QTW10LzSLE1jUDVkBg1oKn1PwVwIO7yeq6R+VJws cFubdL7JOcdzbZl3z9l5jqxvJjT1bLid+Q== X-Google-Smtp-Source: ABdhPJxC3qAvnQwz7E+luTSIs+vtI3r9OV9g+oYs3RNcQcviCeKYBgNXNo/OdMyXBVCyHNajsJZVOA== X-Received: by 2002:a63:c51:0:b0:39c:c5ac:9f3b with SMTP id 17-20020a630c51000000b0039cc5ac9f3bmr23602561pgm.257.1649786058500; Tue, 12 Apr 2022 10:54:18 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id h13-20020a056a00230d00b004f427ffd485sm43049232pfh.143.2022.04.12.10.54.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 10:54:17 -0700 (PDT) Date: Tue, 12 Apr 2022 17:54:14 +0000 From: Sean Christopherson To: Ben Gardon Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Peter Xu , Peter Shier , David Dunn , Junaid Shahid , Jim Mattson , David Matlack , Mingwei Zhang , Jing Zhang Subject: Re: [PATCH v4 07/10] KVM: x86/MMU: Allow NX huge pages to be disabled on a per-vm basis Message-ID: References: <20220411211015.3091615-1-bgardon@google.com> <20220411211015.3091615-8-bgardon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220411211015.3091615-8-bgardon@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.