lkml.org 
[lkml]   [2023]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v10 14/50] crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP
From
Hello Boris,

On 12/9/2023 10:20 AM, Borislav Petkov wrote:
> On Wed, Dec 06, 2023 at 02:35:28PM -0600, Kalra, Ashish wrote:
>> The main use case for the probe parameter is to control if we want to doHl
>> legacy SEV/SEV-ES INIT during probe. There is a usage case where we want to
>> delay legacy SEV INIT till an actual SEV/SEV-ES guest is being launched. So
>> essentially the probe parameter controls if we want to
>> execute __sev_do_init_locked() or not.
>>
>> We always want to do SNP INIT at probe time.
>
> Here's what I mean (diff ontop):
>

See my comments below on this patch:

> +int sev_platform_init(int *error)
> {
> int rc;
>
> mutex_lock(&sev_cmd_mutex);
> - rc = ___sev_platform_init_locked(error, true);
> + rc = _sev_platform_init_locked(error, false);
> mutex_unlock(&sev_cmd_mutex);
>
> return rc;
> }
> +EXPORT_SYMBOL_GPL(sev_platform_init);
>

What we need is a mechanism to do legacy SEV/SEV-ES INIT only if a
SEV/SEV-ES guest is being launched, hence, we want an additional
parameter added to sev_platform_init() exported interface so that
kvm_amd module can call this interface during guest launch and indicate
if SNP/legacy guest is being launched.

That's the reason we want to add the probe parameter to
sev_platform_init().

And to address your previous comments, this will remain a clean
interface, there are going to be only two functions:
sev_platform_init() & __sev_platform_init_locked().

Thanks,
Ashish

\
 
 \ /
  Last update: 2023-12-11 22:12    [W:1.921 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site