Reputation: 769
VMCALL is quite similar to the SYSENTER instruction, differing in the way that SYSENTER is meant for system call (fast transition to the OS), while VMCALL is for hypercalls (transition to hypervisor).
My question is that while SYSENTER does not save the CPU state, does the same apply for VMCALL. Issuing a VMCALL causes a VM exit, but I am not sure if it saves the guest CPU state to the associated VMCS structure or not?
If it does save the CPU state then how exactly can we pass arguments in a hypercall?
Upvotes: 7
Views: 4972
Reputation: 507
VMCS Region is divided into 6 regions, one of which is Guest-state area.
Guest State stores RIP, RFLAGS and RSP on every VMExit. The rest of guest GPRs are live in HW immediately after a VMExit.
VMCALL only causes a VMExit unconditionally. The usage of registers as arguments is left to the api of the VMM.
From Linux KVM API documentation:
Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively. The hypercall number should be placed in rax and the return value will be placed in rax. No other registers will be clobbered unless explicitly stated by the particular hypercall.
From Intel 64 and IA-32 Architectures Software Developer’s Manual:
this instruction does nothing more than cause a VM exit, registering the appropriate exit reason.
From the above I conclude that VMCALL does not preserve any CPU state.
Upvotes: 6