On 1/21/21 9:55 AM, Tejun Heo wrote:

Hello,

On Thu, Jan 21, 2021 at 08:55:07AM -0600, Tom Lendacky wrote:

quoted

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.