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: [RFC PATCH 0/4] SEV-SNP guest policy bit support updates
Date: Wed, 10 Sep 2025 12:23:56 -0700	[thread overview]
Message-ID: <aMHQTFlyv6zHeLex@google.com> (raw)
In-Reply-To: <cover.1755897933.git.thomas.lendacky@amd.com>

On Fri, Aug 22, 2025, Tom Lendacky wrote:
> This series aims to allow more flexibility in specifying SEV-SNP policy
> bits by improving discoverability of supported policy bits from userspace
> and enabling support for newer policy bits.
> 
> - The first patch adds a new KVM_X86_GRP_SEV attribute group,
>   KVM_X86_SNP_POLICY_BITS, that can be used to return the supported
>   SEV-SNP policy bits. The initial support for this attribute will return
>   the current KVM supported policy bitmask.
> 
> - The next 3 patches provide for adding to the known SEV-SNP policy
>   bits. Since some policy bits are dependent on specific levels of SEV
>   firmware support, the CCP driver is updated to provide an API to return
>   the supported policy bits.
> 
>   The supported policy bits bitmask used by KVM is generated by taking the
>   policy bitmask returned by the CCP driver and ANDing it with the KVM
>   supported policy bits. KVM supported policy bits are policy bits that
>   do not require any specific implementation support from KVM to allow.
> 
> This series has a prereq against the ciphertext hiding patches that were
> recently accepted into the cryptodev tree.

I'm still waiting on a stable tag for that branch.  Can I get that, and if the
CCP changes look good, Acks on those patches?  I'd prefer to take this through
kvm-x86 since it adds new uAPI, even though that uAPI is fairly trivial.

Uber nits aside, looks good (though I admittedly haven't stared all that hard).

> The series is based off of:
>   git://git.kernel.org/pub/scm/virt/kvm/kvm.git next
> 
>   with the added the ciphertext hiding patches
> 
> Tom Lendacky (4):
>   KVM: SEV: Publish supported SEV-SNP policy bits
>   KVM: SEV: Consolidate the SEV policy bits in a single header file
>   crypto: ccp - Add an API to return the supported SEV-SNP policy bits
>   KVM: SEV: Add known supported SEV-SNP policy bits
> 
>  arch/x86/include/uapi/asm/kvm.h |  1 +
>  arch/x86/kvm/svm/sev.c          | 45 +++++++++++++++++++++------------
>  arch/x86/kvm/svm/svm.h          |  3 ---
>  drivers/crypto/ccp/sev-dev.c    | 37 +++++++++++++++++++++++++++
>  include/linux/psp-sev.h         | 39 ++++++++++++++++++++++++++++
>  5 files changed, 106 insertions(+), 19 deletions(-)
> 
> 
> base-commit: 82a56258ec2d48f9bb1e9ce8f26b14c161dfe4fb
> -- 
> 2.46.2
> 

      parent reply	other threads:[~2025-09-10 19:23 UTC|newest]

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

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=aMHQTFlyv6zHeLex@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.