Messages in this thread | | | Date | Mon, 27 Nov 2023 16:00:50 -0800 | From | Dave Hansen <> | Subject | AMD Memory encryption vs. kexec |
| |
... actually cc'd the mailing lists and x86@ exploder on this one. Please reply here.
---
There are two kexec-related wbinvd's:
One for the kexec boot CPU in relocate_kernel() which is driven by CC_ATTR_HOST_MEM_ENCRYPT:
> image->start = relocate_kernel((unsigned long)image->head, > (unsigned long)page_list, > image->start, > image->preserve_context, > cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT));
the other is for non-boot CPUs in stop_this_cpu():
> if (c->extended_cpuid_level >= 0x8000001f && (cpuid_eax(0x8000001f) & BIT(0))) > native_wbinvd();
By my reading, the CC_ATTR_HOST_MEM_ENCRYPT is basically a check for whether the current kernel has enabled SME but not SEV while the stop_this_cpu() site is driven purely by whether the hardware *supports* SME.
The whole supposed reason stop_this_cpu() checks CPUID directly is that the current kernel SME/SEV enabling might not match the _next_ kernel's enabling choices.
So, why is a _current_ kernel check OK for relocate_kernel(), but not OK for stop_this_cpu()?
It seems to me like both sites might need to use the stop_this_cpu()-style "raw" hardware support checks.
Why do I care? TDX potentially needs wbinvd at the same two spots. It would be nice to have a common cc_attr for both sites, but I need to reconcile the apparently disparate AMD uses first.
| |