On 1/21/21 9:55 AM, Tejun Heo wrote:
Hello,
On Thu, Jan 21, 2021 at 08:55:07AM -0600, Tom Lendacky wrote:
The hardware will allow any SEV capable ASID to be run as SEV-ES, however,
the SEV firmware will not allow the activation of an SEV-ES VM to be
assigned to an ASID greater than or equal to the SEV minimum ASID value. The
reason for the latter is to prevent an !SEV-ES ASID starting out as an
SEV-ES guest and then disabling the SEV-ES VMCB bit that is used by VMRUN.
This would result in the downgrading of the security of the VM without the
VM realizing it.
As a result, you have a range of ASIDs that can only run SEV-ES VMs and a
range of ASIDs that can only run SEV VMs.
I see. That makes sense. What's the downside of SEV-ES compared to SEV w/o
ES? Are there noticeable performance / feature penalties or is the split
mostly for backward compatibility?
SEV-ES is an incremental enhancement of SEV where the register state of
the guest is protected/encrypted. As with a lot of performance questions,
the answer is ...it depends. With SEV-ES, there is additional overhead
associated with a world switch (VMRUN/VMEXIT) to restore and save
additional register state. Also, exit events are now divided up into
automatic exits (AE) and non-automatic exits (NAE). NAE events result in a
new #VC exception being generated where the guest is then required to use
the VMGEXIT instruction to communicate only the state necessary to perform
the operation. A CPUID instruction is a good example, where a shared page
is used to communicate required state to the hypervisor to perform the
CPUID emulation, which then returns the results back through the shared
page to the guest. So it all depends on how often the workload in question
performs operations that result in a VMEXIT of the vCPU, etc.
Thanks,
Tom
Thanks.
