All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	x86@kernel.org,  linux-crypto@vger.kernel.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	 Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	 Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	 Michael Roth <michael.roth@amd.com>,
	Ashish Kalra <ashish.kalra@amd.com>,
	 Herbert Xu <herbert@gondor.apana.org.au>,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH v3 3/4] crypto: ccp - Add an API to return the supported SEV-SNP policy bits
Date: Thu, 23 Oct 2025 09:37:02 -0700	[thread overview]
Message-ID: <aPpZrpfes8-SY4k_@google.com> (raw)
In-Reply-To: <3a86b3678a78a8b720d3818f4121972f67e2d0a8.1761154644.git.thomas.lendacky@amd.com>

On Wed, Oct 22, 2025, Tom Lendacky wrote:
> Supported policy bits are dependent on the level of SEV firmware that is
> currently running. Create an API to return the supported policy bits for
> a given level of firmware. KVM will AND that value with the KVM supported

Given "KVM will AND" and the shortlog, I expected a _future_ patch to have the 
           ^^^^
KVM changes.

That's partly a PEBKAC on my end (I mean, it's literally the first diff), but I
do think it highlights that we should probably separate the KVM change from the
PSP support. 

Hmm, actually, the patch ordering is bad.  There shouldn't need to be a separate
KVM change after this commit, because as things are ordered now, there will be an
ABI change between patch 1 and this patch.

So I think what you want is:

  1. KVM: SEV: Consolidate the SEV policy bits in a single header file
  2. crypto: ccp - Add an API to return the supported SEV-SNP policy bits
  3. KVM: SEV: Publish supported SEV-SNP policy bits
  4. KVM: SEV: Add known supported SEV-SNP policy bits

where #3 uses sev_get_snp_policy_bits() straightaway.

> policy bits to generate the actual supported policy bits.
> 
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  arch/x86/kvm/svm/sev.c       |  3 ++-
>  drivers/crypto/ccp/sev-dev.c | 37 ++++++++++++++++++++++++++++++++++++
>  include/linux/psp-sev.h      | 20 +++++++++++++++++++
>  3 files changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 45e87d756e15..24167178bf05 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -3099,7 +3099,8 @@ void __init sev_hardware_setup(void)
>  			sev_snp_supported = is_sev_snp_initialized();
>  
>  		if (sev_snp_supported) {
> -			snp_supported_policy_bits = KVM_SNP_POLICY_MASK_VALID;
> +			snp_supported_policy_bits = sev_get_snp_policy_bits();
> +			snp_supported_policy_bits &= KVM_SNP_POLICY_MASK_VALID;

I vote for:

			snp_supported_policy_bits = sev_get_snp_policy_bits() &
						    KVM_SNP_POLICY_MASK_VALID;

which makes it visually easier to see the policy bits logic.
	
>  			nr_ciphertext_hiding_asids = init_args.max_snp_asid;
>  		}

  reply	other threads:[~2025-10-23 16:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-22 17:37 [PATCH v3 0/4] SEV-SNP guest policy bit support updates Tom Lendacky
2025-10-22 17:37 ` [PATCH v3 1/4] KVM: SEV: Publish supported SEV-SNP policy bits Tom Lendacky
2025-10-22 17:37 ` [PATCH v3 2/4] KVM: SEV: Consolidate the SEV policy bits in a single header file Tom Lendacky
2025-10-22 17:37 ` [PATCH v3 3/4] crypto: ccp - Add an API to return the supported SEV-SNP policy bits Tom Lendacky
2025-10-23 16:37   ` Sean Christopherson [this message]
2025-10-23 17:36     ` Tom Lendacky
2025-10-22 17:37 ` [PATCH v3 4/4] KVM: SEV: Add known " Tom Lendacky

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=aPpZrpfes8-SY4k_@google.com \
    --to=seanjc@google.com \
    --cc=ashish.kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=kvm@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /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.