Messages in this thread | | | Subject | Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted | From | David Woodhouse <> | Date | Thu, 09 Mar 2023 15:45:35 +0000 |
| |
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. [unhandled content-type:application/pkcs7-signature] | |