I have a question about AMD's upcoming SEV-SNP feature. I was reading the AMD64 software developer's manual (hyper-linked) and saw the Virtual Machine Privilege Levels (VMPL) feature (to be included with SEV-SNP). I was wondering how the feature is activated by the guest and how can a guest switch the VMPL-levels of its vCPUs? I couldn't find an answer to these questions in the manual.
Each VMSA defines the VMPL that it executes at (as noted in Table B-4). For example, a guest must have 2 VMSAs, the first is defined to run at VMPL0 and the second at VMPL1. To switch between these, the guest must coordinate with the hypervisor. For instance, the hypervisor may have first run the VMPL1 VMSA and that code decides it needs a service from VMPL0. That code would do a hypercall to ask the hypervisor to switch to the other VMSA. In response to this, the hypervisor should do ‘VMRUN’ on the VMPL0 VMSA and allow it to execute. When this is finished, it can ask the hypervisor to switch back again via a hypercall.
One way we expect this feature may be used would be for every vCPU of the guest to contain VMSAs at multiple levels. For instance, the ‘rich OS’ might have a VMSA defined to run at VMPL1 while a ‘trusted layer’ has its own VMSA defined to run at VMPL0. That trusted layer might be responsible for tasks like APIC emulation, migration, etc. By default, the hypervisor would run the VMPL1 VMSA but if it needed a service from the trusted layer (e.g. handle an ICR write) then the hypervisor would switch over to VMPL0 so the trusted layer could handle the event. After this is done, the hypervisor could switch back to VMPL0.
Hope this helps.
Yeah, I saw the VMPL bit in the VMSA but I was wondering if there is a more efficient way to switch the VMPL without exiting the guest. It seems that there isn't for now, at least.
Thanks for the clarification!
Another question that I had in mind was that for an SEV guest, each hypercall must definitely flush the TLB; hence, hypercalls are way more expensive than regular guests? Is my understanding valid?
VMEXIT events (whether for hypercalls or due to other reasons) do not flush the TLB. The TLB entries are tagged as described in APM vol2 section 15.36.15 and this ensures that incorrect translations can’t be used.
In general, encrypted guests do have additional overhead due to the extra security checks and state that must be saved/restored. But TLB flushes are not needed.
Awesome, got it!
Thanks a bunch for all the clarifications!
Hi, I have another clarification to ask. As you said, we can use VMSAs for creating a tiny secure layer and a rich OS. Can we also create let's say a VMSA for a user process, instead of privileged components?