Currently, when the guest running at VMPL2 switches back to the SVSM it is assumed that the guest VMSA virtual memory mapping is correct. However, it is possible for the VMPL2 AP to be destroyed and recreated while the AP request loop is blocked on waiting for the guest VMPL to call back to the SVSM. In this case the VMSA mapping is incorrect and the SVSM call fails.
This is fixed by updating the mappings on returning to the SVSM from the guest VMPL.
Currently, when the guest running at VMPL2 switches back to the SVSM it is assumed that the guest VMSA virtual memory mapping is correct. However, it is possible for the VMPL2 AP to be destroyed and recreated while the AP request loop is blocked on waiting for the guest VMPL to call back to the SVSM. In this case the VMSA mapping is incorrect and the SVSM call fails.
This is fixed by updating the mappings on returning to the SVSM from the guest VMPL.