From: Sean Christopherson <seanjc@google.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Borislav Petkov <bp@suse.de>,
Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [PATCH 11/13] KVM: SVM: Drop redundant svm_sev_enabled() helper
Date: Mon, 11 Jan 2021 12:59:33 -0800 [thread overview]
Message-ID: <X/y8NU4hWWKgGrJo@google.com> (raw)
In-Reply-To: <89efe8fb-6495-5634-9378-a7dbb57f9d81@amd.com>
On Mon, Jan 11, 2021, Tom Lendacky wrote:
> On 1/8/21 6:47 PM, Sean Christopherson wrote:
> > Replace calls to svm_sev_enabled() with direct checks on sev_enabled, or
> > in the case of svm_mem_enc_op, simply drop the call to svm_sev_enabled().
> > This effectively replaces checks against a valid max_sev_asid with checks
> > against sev_enabled. sev_enabled is forced off by sev_hardware_setup()
> > if max_sev_asid is invalid, all call sites are guaranteed to run after
> > sev_hardware_setup(), and all of the checks care about SEV being fully
> > enabled (as opposed to intentionally handling the scenario where
> > max_sev_asid is valid but SEV enabling fails due to OOM).
> >
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> > arch/x86/kvm/svm/sev.c | 6 +++---
> > arch/x86/kvm/svm/svm.h | 5 -----
> > 2 files changed, 3 insertions(+), 8 deletions(-)
> >
>
> With CONFIG_KVM=y, CONFIG_KVM_AMD=y and CONFIG_CRYPTO_DEV_CCP_DD=m, I get
> the following build warning:
...
> In function ‘bitmap_zero’,
> inlined from ‘__sev_recycle_asids’ at arch/x86/kvm/svm/sev.c:92:2,
> inlined from ‘sev_asid_new’ at arch/x86/kvm/svm/sev.c:113:16,
> inlined from ‘sev_guest_init’ at arch/x86/kvm/svm/sev.c:195:9:
> ./include/linux/bitmap.h:238:2: warning: argument 1 null where non-null expected [-Wnonnull]
> 238 | memset(dst, 0, len);
> | ^~~~~~~~~~~~~~~~~~~
Ah, because that config "silently" disables CONFIG_KVM_AMD_SEV. The warning
pops up because svm_sev_enabled() included !IS_ENABLED(CONFIG_KVM_AMD_SEV) and
that was enough for the compiler to understand that svm_mem_enc_op() was a nop.
That being said, unless I'm missing something, this is a false positive the
compiler's part, e.g. the warning occurs even if sev_enabled is false be default,
i.e. CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=n.
Anyways, I'm leaning towards "fixing" this by defining sev_enabled and
sev_es_enabled to false if CONFIG_KVM_AMD_SEV=n. It'd be a worthwhile change to
condition the default values on CONFIG_KVM_AMD_SEV anyways, so it'd kill two
birds with one stone. Long term, I'm tempted to exporing conditioning all of
sev.c on CONFIG_KVM_AMD_SEV=y, but there are just enough functions exposed via
svm.h that make me think it wouldn't be worth the effort.
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 1b9174a49b65..7e14514dd083 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -28,12 +28,17 @@
#define __ex(x) __kvm_handle_fault_on_reboot(x)
/* enable/disable SEV support */
+#ifdef CONFIG_KVM_AMD_SEV
static bool sev_enabled = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
module_param_named(sev, sev_enabled, bool, 0444);
/* enable/disable SEV-ES support */
static bool sev_es_enabled = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
module_param_named(sev_es, sev_es_enabled, bool, 0444);
+#else
+#define sev_enabled false
+#define sev_es_enabled false
+#endif /* CONFIG_KVM_AMD_SEV */
static u8 sev_enc_bit;
static int sev_flush_asids(void);
@@ -1253,11 +1258,12 @@ void sev_vm_destroy(struct kvm *kvm)
void __init sev_hardware_setup(void)
{
+#ifdef CONFIG_KVM_AMD_SEV
unsigned int eax, ebx, ecx, edx;
bool sev_es_supported = false;
bool sev_supported = false;
- if (!IS_ENABLED(CONFIG_KVM_AMD_SEV) || !sev_enabled)
+ if (!sev_enabled)
goto out;
/* Does the CPU support SEV? */
@@ -1310,6 +1316,7 @@ void __init sev_hardware_setup(void)
out:
sev_enabled = sev_supported;
sev_es_enabled = sev_es_supported;
+#endif
}
void sev_hardware_teardown(void)
next prev parent reply other threads:[~2021-01-11 21:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-09 0:47 [PATCH 00/13] KVM: SVM: Misc SEV cleanups Sean Christopherson
2021-01-09 0:47 ` [PATCH 01/13] KVM: SVM: Free sev_asid_bitmap during init if SEV setup fails Sean Christopherson
2021-01-11 14:42 ` Tom Lendacky
2021-01-11 18:07 ` Sean Christopherson
2021-01-09 0:47 ` [PATCH 02/13] KVM: SVM: Zero out the VMCB array used to track SEV ASID association Sean Christopherson
2021-01-09 0:47 ` [PATCH 03/13] KVM: SVM: Move SEV module params/variables to sev.c Sean Christopherson
2021-01-11 10:42 ` Vitaly Kuznetsov
2021-01-11 15:36 ` Tom Lendacky
2021-01-11 16:58 ` Vitaly Kuznetsov
2021-01-12 22:18 ` Sean Christopherson
2021-01-11 15:30 ` Tom Lendacky
2021-01-09 0:47 ` [PATCH 04/13] x86/cpufeatures: Assign dedicated feature word for AMD mem encryption Sean Christopherson
2021-01-09 0:47 ` [PATCH 05/13] KVM: x86: Override reported SME/SEV feature flags with host mask Sean Christopherson
2021-01-09 0:47 ` [PATCH 06/13] x86/sev: Rename global "sev_enabled" flag to "sev_guest" Sean Christopherson
2021-01-11 16:02 ` Tom Lendacky
2021-01-11 16:47 ` Tom Lendacky
2021-01-11 17:58 ` Sean Christopherson
2021-01-11 20:28 ` Sean Christopherson
2021-01-09 0:47 ` [PATCH 07/13] KVM: SVM: Append "_enabled" to module-scoped SEV/SEV-ES control variables Sean Christopherson
2021-01-11 16:03 ` Tom Lendacky
2021-01-09 0:47 ` [PATCH 08/13] KVM: SVM: Unconditionally invoke sev_hardware_teardown() Sean Christopherson
2021-01-09 0:47 ` [PATCH 09/13] KVM: SVM: Explicitly check max SEV ASID during sev_hardware_setup() Sean Christopherson
2021-01-09 0:47 ` [PATCH 10/13] KVM: SVM: Move SEV VMCB tracking allocation to sev.c Sean Christopherson
2021-01-09 0:47 ` [PATCH 11/13] KVM: SVM: Drop redundant svm_sev_enabled() helper Sean Christopherson
2021-01-11 17:57 ` Tom Lendacky
2021-01-11 20:59 ` Sean Christopherson [this message]
2021-01-09 0:47 ` [PATCH 12/13] KVM: SVM: Remove an unnecessary prototype declaration of sev_flush_asids() Sean Christopherson
2021-01-09 0:47 ` [PATCH 13/13] KVM: SVM: Skip SEV cache flush if no ASIDs have been used Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X/y8NU4hWWKgGrJo@google.com \
--to=seanjc@google.com \
--cc=bp@suse.de \
--cc=brijesh.singh@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=thomas.lendacky@amd.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.