On Thu, Mar 21, 2024 at 09:48:28AM +1300, Huang, Kai wrote:
Hi Tom,
I am not aware of kexec() support status for SEV-ES/SEV-SNP guests.
Does patch 1 break them?
SNP guests can kexec with some patches that are currently in process
around shared to private memory conversions. ES guests can only kexec
with a single vCPU. There was a recent patch series to add support for
multiple vCPUs.
Patch #1 doesn't break either ES or SNP because we still have an IDT and
traditional kernel addressing in place, so the #VC can be handled.
How about plain SEV guest?
Whereas patch #2 has switched to identity mapping and removed the IDT,
so a #VC causes a triple fault.
That makes sense. Thanks.
Hi Kirill,
Does TDX guest have similar behaviour -- that WBINVD in stop_this_cpu() can
be handled although it causes #VE, while WBINVD in relocate_kernel() will
just triple fault the guest?
No. We never handle WBINVD #VE. Guest cannot handle WBINVD itself and the
only option is to ask host to do this. We cannot guarantee host will do
anything useful with the request. I guess it can be potential attack
vector if host strategically ignores WBINVD to induce bad guest behaviour.
And it is not good from host PoV either. If it does WBINVD on every guest
request we get guest->host DoS attack possibility.
Tom, I am curious, how do you deal with these problems?