On Thu, 2023-03-09 at 15:45 +0100, Borislav Petkov wrote: > On Thu, Mar 09, 2023 at 03:36:45PM +0100, Jörg Rödel wrote: > > Yes, that is right. The key is mainly for the NMI entry path which can > > be performance relevant in some situations. For SEV-ES some special > > handling is needed there to re-enable NMIs and adjust the #VC stack in > > case it was raised on the VC-handlers entry path. > > So the performance argument is meh. That key will be replaced by > > if (cc_vendor == CC_VENDOR_AMD && > cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT) > > which is something like 4 insns or so. Tops. > > Haven't looked yet but it should be cheap. cc_vendor isn't yet exposed. As we discussed this in IRC, I've been updating the parallel bringup support for SEV-ES, including adding a cc_get_vendor() function, in the top of my tree at https://git.infradead.org/users/dwmw2/linux.git/commitdiff/parallel-6.2-v15 and it now looks like this: /* * 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)) { switch (cc_get_vendor()) { case CC_VENDOR_AMD: has_sev_es = true; break; default: pr_info("Disabling parallel bringup due to guest state encryption\n"); return false; } } Using an explicit CC_ATTR_NO_EARLY_CPUID flag instead of CC_ATTR_GUEST_STATE_ENCRYPT which is merely an approximation of that, might be interesting.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
