Messages in this thread | | | Date | Mon, 11 Dec 2023 15:11:17 -0600 | Subject | Re: [PATCH v10 14/50] crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP | From | "Kalra, Ashish" <> |
| |
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
| |