Received-SPF: pass (google.com: domain of linux-kernel+bounces-47236-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 31 Jan 2024 14:15:08 -0800
In-Reply-To: <20240104190520.62510-1-Ashish.Kalra@amd.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240104190520.62510-1-Ashish.Kalra@amd.com>
Message-ID: <ZbrGbLLvdwRfMun5@google.com>
Subject: Re: [PATCH v3] x86/sev: Add support for allowing zero SEV ASIDs.
From: Sean Christopherson <seanjc@google.com>
To: Ashish Kalra <Ashish.Kalra@amd.com>
Cc: pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, 
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, 
	thomas.lendacky@amd.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, 
	joro@8bytes.org
Content-Type: text/plain; charset="us-ascii"

On Thu, Jan 04, 2024, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
> 
> Some BIOSes allow the end user to set the minimum SEV ASID value
> (CPUID 0x8000001F_EDX) to be greater than the maximum number of
> encrypted guests, or maximum SEV ASID value (CPUID 0x8000001F_ECX)
> in order to dedicate all the SEV ASIDs to SEV-ES or SEV-SNP.
> 
> The SEV support, as coded, does not handle the case where the minimum
> SEV ASID value can be greater than the maximum SEV ASID value.
> As a result, the following confusing message is issued:
> 
> [   30.715724] kvm_amd: SEV enabled (ASIDs 1007 - 1006)
> 
> Fix the support to properly handle this case.
> 
> Fixes: 916391a2d1dc ("KVM: SVM: Add support for SEV-ES capability in KVM")
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> Cc: stable@vger.kernel.org
> ---
>  arch/x86/kvm/svm/sev.c | 40 ++++++++++++++++++++++++----------------

This should be ~3 patches:

 1. Convert ASID variables/params to unsigned integers.
 2. Return -EINVAL instead of -EBUSY
 3. The actual fix here

E.g if #2 breaks userspace (extremely unlikely) then bisection should point at
exactly that, not at a commit with a whole pile of unrelated things going on.

I'll send a v4, #1 should also be accompanied by a cleanup of sev_asid_new() to
not multiplex the ASID with the return code.  It can simply set sev->asid directly,
which as a bonus makes sev_asid_new() and sev_asid_free() more symmetric.