mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: "Kalra, Ashish" <ashish.kalra@amd.com>,
	seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	hpa@zytor.com, herbert@gondor.apana.org.au
Cc: x86@kernel.org, john.allen@amd.com, davem@davemloft.net,
	michael.roth@amd.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH v4 2/5] crypto: ccp: Add support for SNP_FEATURE_INFO command
Date: Thu, 5 Jun 2025 10:51:11 -0500	[thread overview]
Message-ID: <9cac6024-2e13-12ae-24f2-2f1668691935@amd.com> (raw)
In-Reply-To: <9af40b3b-91d5-4758-abee-070fbf3ff52f@amd.com>

On 6/4/25 17:52, Kalra, Ashish wrote:
> Hello Tom,
> 
> On 6/3/2025 10:21 AM, Tom Lendacky wrote:
>> On 5/19/25 18:56, Ashish Kalra wrote:
>>> From: Ashish Kalra <ashish.kalra@amd.com>
>>>
>>>
>>> Switch to using SNP platform status instead of SEV platform status if
>>> SNP is enabled and cache SNP platform status and feature information
>>> from CPUID 0x8000_0024, sub-function 0, in the sev_device structure.
>>
>> Since the SEV platform status and SNP platform status differ, I think this
>> patch should be split into two separate patches.
>>
>> The first first patch would cache the current SEV platform status return
>> structure and eliminate the separate state field (as state is unique
>> between SEV and SNP).
> 
> Eliminate the state field ? 
> 
> But isn't the sev_device->state field used also as driver's internal state information
> and not directly mapped to platform status, except the initial state is the platform state 
> on module load, so why to remove the field altogether ?

Well the state of SEV and SNP are different, so they need to be tracked
separately (or at least better clarified in the code that the current
state field is tracking the SEV state). Since the state field is part of
the platform status, you can just update that field. Not sure what it will
look like.

The current state is only SEV related because SNP only has UNINIT and INIT
and so the snp_initialized flag is used instead.

Thanks,
Tom

> 

  reply	other threads:[~2025-06-05 15:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-19 23:56 [PATCH v4 0/5] Add SEV-SNP CipherTextHiding feature support Ashish Kalra
2025-05-19 23:56 ` [PATCH v4 1/5] crypto: ccp: New bit-field definitions for SNP_PLATFORM_STATUS command Ashish Kalra
2025-06-03 14:03   ` Tom Lendacky
2025-05-19 23:56 ` [PATCH v4 2/5] crypto: ccp: Add support for SNP_FEATURE_INFO command Ashish Kalra
2025-06-03 15:21   ` Tom Lendacky
2025-06-04 22:52     ` Kalra, Ashish
2025-06-05 15:51       ` Tom Lendacky [this message]
2025-06-05  4:49   ` Alexey Kardashevskiy
2025-06-05 19:34     ` Kalra, Ashish
2025-05-19 23:57 ` [PATCH v4 3/5] crypto: ccp: Add support to enable CipherTextHiding on SNP_INIT_EX Ashish Kalra
2025-06-03 15:41   ` Tom Lendacky
2025-06-04 22:55     ` Kalra, Ashish
2025-06-05  6:32   ` Alexey Kardashevskiy
2025-06-05 19:09     ` Kalra, Ashish
2025-05-19 23:57 ` [PATCH v4 4/5] KVM: SEV: Introduce new min,max sev_es and sev_snp asid variables Ashish Kalra
2025-06-03 15:52   ` Tom Lendacky
2025-06-04 23:12     ` Kalra, Ashish
2025-05-20  0:02 ` [PATCH v4 5/5] KVM: SEV: Add SEV-SNP CipherTextHiding support Ashish Kalra
2025-05-23 17:29   ` Dave Hansen
2025-06-02 20:32     ` Kalra, Ashish
2025-06-03 16:26   ` Tom Lendacky
2025-06-05  0:17     ` Kalra, Ashish
2025-06-05 16:23       ` Tom Lendacky
2025-06-05 19:21         ` Kalra, Ashish
2025-06-05  6:32   ` Alexey Kardashevskiy
2025-06-05 19:18     ` Kalra, Ashish
2025-05-22 14:56 ` [PATCH v4 0/5] Add SEV-SNP CipherTextHiding feature support Kim Phillips
2025-05-27 20:47   ` Kalra, Ashish

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=9cac6024-2e13-12ae-24f2-2f1668691935@amd.com \
    --to=thomas.lendacky@amd.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=hpa@zytor.com \
    --cc=john.allen@amd.com \
    --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=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®