On Thu, 2023-03-09 at 12:59 +0100, Borislav Petkov wrote:
>
> So looking at sev_es_init_vc_handling() where we set that key, I'm
> *thinking* that key can be removed now and the code should check
>
> cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT)
>
> instead.
>
> Because if some of the checks in that function below fail, the guest
> will terminate anyway.
>
> Jörg, Tom?
Hrm... the implication of that is that I should do something like this
in my own code. Is this really your intent?
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index b4265c5b46da..7ac4ec6415de 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1519,24 +1519,17 @@ void __init smp_prepare_cpus_common(void)
*/
static bool prepare_parallel_bringup(void)
{
- bool has_sev_es = sev_es_active();
+ /*
+ * The "generic" CC_ATTR_GUEST_STATE_ENCRYPT actually means specifically
+ * SEV-ES, and only SEV-ES, and always shall mean that. If it's present,
+ * that means the AP startup code should use the hard-coded SEV-ES GHCB
+ * call to find its APIC ID (STARTUP_APICID_SEV_ES).
+ */
+ bool has_sev_es = cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT);
if (IS_ENABLED(CONFIG_X86_32))
return false;
- /*
- * Encrypted guests other than SEV-ES (in the future) will need to
- * implement an early way of finding the APIC ID, since they will
- * presumably block direct CPUID too. Be kind to our future selves
- * by warning here instead of just letting them break. Parallel
- * startup doesn't have to be in the first round of enabling patches
- * for any such technology.
- */
- if (cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT) && !has_sev_es) {
- pr_info("Disabling parallel bringup due to guest memory encryption\n");
- return false;
- }
-
if (x2apic_mode || has_sev_es) {
if (boot_cpu_data.cpuid_level < 0x0b)
return false;
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
