Hello adilahmad17,
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.
