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 4074CC41513 for ; Wed, 16 Aug 2023 21:42:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346601AbjHPVmN (ORCPT ); Wed, 16 Aug 2023 17:42:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346628AbjHPVls (ORCPT ); Wed, 16 Aug 2023 17:41:48 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12C972D4B for ; Wed, 16 Aug 2023 14:41:36 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-58cf42a3313so11183697b3.0 for ; Wed, 16 Aug 2023 14:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692222095; x=1692826895; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=TsYuTaSOsfwoUfIhRlrKvY32E50+S15G9LijBCHGyrU=; b=Jucm9s2GWuF08tuKKlcouSI/r5ZfGZfg4Cf8kO7ENSxpx2LLd2Mccj4JJ/nRYnBp2g o52Xy79FlQlvRobKzgaBMdk/udiMgR1loB8R9vm2TpzYJIYP+LfEUCFvpJ2cGWJfzI/L MEBpYmdpR0GtbARk3kTRy4s/EN+RJtZHkxc9nzZvZ6IA5zyJdVLtDg21L8qnkUwwrZm9 Vaqs5HSLtJdQE/HOOVsPhf5trydIU4Ju0dUajd5QVgxcHU80XiaP0oRJhfSSy4f7Me3o XNtVY7jzhUVe56QYeYRXad6ZrA5cUYTWXhMbgAGX0KGqDyxoBZEIyUp2xkLt9CAMwgts jtKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692222095; x=1692826895; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TsYuTaSOsfwoUfIhRlrKvY32E50+S15G9LijBCHGyrU=; b=XicPpjRPRhDyg+X9LNsUOtc4/eccx/FDZDJpctLDLD496kiDERtyZxqf6ekRvQFFkH UfOVHB8txuLs2RVK5RmkUd9qOFPnYFN8EVVQRerhoq/YLBF7nB8bZ6LryaT+zuXSlQVG 25RGMPt1VZP4Kp/MH/U2sC9puJpx60Faej4JGaMe8q3KafgfRzUGl75g/JkaeXAozXIO oCT86fiqVgBH5EKJZ+gwInqmLZlO5zy46yZa58di3pbq44ffyVvJxlMhn6CyibNo8tCh Yf7vD8/e28psm4JS8IvxSFUksiyb8hHdUaCB8+VKk2qxWDFRXoJVb36ZlMUFSHb/Sfkg aIVw== X-Gm-Message-State: AOJu0YxCk0yMLM78M/t0c+ihsKX9Wr3Zod2nOCgkOjdPEqBCx+6q3JmR Z4e4D/uHK7YkPOq/41bmzKfnQ3Rho8w= X-Google-Smtp-Source: AGHT+IEiKexpH65z/3ob4P3GzM4VmLMOzuc++j2jgqrwf3M6ZzbavNQxJ65hw7yzlCAttFXohCNW7FMqdMw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:4524:0:b0:58c:74ec:3394 with SMTP id s36-20020a814524000000b0058c74ec3394mr47263ywa.5.1692222095367; Wed, 16 Aug 2023 14:41:35 -0700 (PDT) Date: Wed, 16 Aug 2023 14:41:33 -0700 In-Reply-To: <20230719144131.29052-5-binbin.wu@linux.intel.com> Mime-Version: 1.0 References: <20230719144131.29052-1-binbin.wu@linux.intel.com> <20230719144131.29052-5-binbin.wu@linux.intel.com> Message-ID: Subject: Re: [PATCH v10 4/9] KVM: x86: Virtualize CR4.LAM_SUP From: Sean Christopherson To: Binbin Wu Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, chao.gao@intel.com, kai.huang@intel.com, David.Laight@aculab.com, robert.hu@linux.intel.com, guang.zeng@intel.com Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch doesn't virtualize LAM_SUP, it simply allows the guest to enable CR4.LAM_SUP (ignoring that that's not possible at this point because KVM will reject CR4 values that *KVM* doesn't support). Actually virtualizing LAM_SUP requires the bits from "KVM: VMX: Implement and wire get_untagged_addr() for LAM". You can still separate LAM_SUP from LAM_U*, but these patches should come *after* the get_untagged_addr() hook is added. The first of LAM_SUP vs. LAM_U* can then implement vmx_get_untagged_addr(), and simply return the raw gva in the "other" case. E.g. if you add LAM_SUP first, the code can be: if (!(gva & BIT_ULL(63))) { /* KVM doesn't yet virtualize LAM_U{48,57}. */ return false; } else { if (!kvm_is_cr4_bit_set(vcpu, X86_CR4_LAM_SUP)) return gva; lam_bit = kvm_is_cr4_bit_set(vcpu, X86_CR4_LA57) ? 56 : 47; } On Wed, Jul 19, 2023, Binbin Wu wrote: > From: Robert Hoo > > Add support to allow guests to set the new CR4 control bit for guests to enable > the new Intel CPU feature Linear Address Masking (LAM) on supervisor pointers. > > LAM modifies the checking that is applied to 64-bit linear addresses, allowing > software to use of the untranslated address bits for metadata and masks the > metadata bits before using them as linear addresses to access memory. LAM uses > CR4.LAM_SUP (bit 28) to configure LAM for supervisor pointers. LAM also changes > VMENTER to allow the bit to be set in VMCS's HOST_CR4 and GUEST_CR4 for > virtualization. Note CR4.LAM_SUP is allowed to be set even not in 64-bit mode, > but it will not take effect since LAM only applies to 64-bit linear addresses. > > Move CR4.LAM_SUP out of CR4_RESERVED_BITS and its reservation depends on vcpu > supporting LAM feature or not. Leave the bit intercepted to prevent guest from > setting CR4.LAM_SUP bit if LAM is not exposed to guest as well as to avoid vmread > every time when KVM fetches its value, with the expectation that guest won't > toggle the bit frequently. > > Set CR4.LAM_SUP bit in the emulated IA32_VMX_CR4_FIXED1 MSR for guests to allow > guests to enable LAM for supervisor pointers in nested VMX operation. > > Hardware is not required to do TLB flush when CR4.LAM_SUP toggled, KVM doesn't > need to emulate TLB flush based on it. > There's no other features/vmx_exec_controls connection, no other code needed in > {kvm,vmx}_set_cr4(). > > Signed-off-by: Robert Hoo > Co-developed-by: Binbin Wu > Signed-off-by: Binbin Wu > Reviewed-by: Chao Gao > Reviewed-by: Kai Huang > Tested-by: Xuelian Guo > --- > arch/x86/include/asm/kvm_host.h | 3 ++- > arch/x86/kvm/vmx/vmx.c | 3 +++ > arch/x86/kvm/x86.h | 2 ++ > 3 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > index e8e1101a90c8..881a0be862e1 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -125,7 +125,8 @@ > | X86_CR4_PGE | X86_CR4_PCE | X86_CR4_OSFXSR | X86_CR4_PCIDE \ > | X86_CR4_OSXSAVE | X86_CR4_SMEP | X86_CR4_FSGSBASE \ > | X86_CR4_OSXMMEXCPT | X86_CR4_LA57 | X86_CR4_VMXE \ > - | X86_CR4_SMAP | X86_CR4_PKE | X86_CR4_UMIP)) > + | X86_CR4_SMAP | X86_CR4_PKE | X86_CR4_UMIP \ > + | X86_CR4_LAM_SUP)) > > #define CR8_RESERVED_BITS (~(unsigned long)X86_CR8_TPR) > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index ae47303c88d7..a0d6ea87a2d0 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -7646,6 +7646,9 @@ static void nested_vmx_cr_fixed1_bits_update(struct kvm_vcpu *vcpu) > cr4_fixed1_update(X86_CR4_UMIP, ecx, feature_bit(UMIP)); > cr4_fixed1_update(X86_CR4_LA57, ecx, feature_bit(LA57)); > > + entry = kvm_find_cpuid_entry_index(vcpu, 0x7, 1); > + cr4_fixed1_update(X86_CR4_LAM_SUP, eax, feature_bit(LAM)); > + > #undef cr4_fixed1_update > } > > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h > index 82e3dafc5453..24e2b56356b8 100644 > --- a/arch/x86/kvm/x86.h > +++ b/arch/x86/kvm/x86.h > @@ -528,6 +528,8 @@ bool kvm_msr_allowed(struct kvm_vcpu *vcpu, u32 index, u32 type); > __reserved_bits |= X86_CR4_VMXE; \ > if (!__cpu_has(__c, X86_FEATURE_PCID)) \ > __reserved_bits |= X86_CR4_PCIDE; \ > + if (!__cpu_has(__c, X86_FEATURE_LAM)) \ > + __reserved_bits |= X86_CR4_LAM_SUP; \ > __reserved_bits; \ > }) > > -- > 2.25.1 >