kvm: nVMX: Use nested_run_pending rather than from_vmentry
authorJim Mattson <jmattson@google.com>
Thu, 26 Apr 2018 23:09:12 +0000 (16:09 -0700)
committerRadim Krčmář <rkrcmar@redhat.com>
Wed, 23 May 2018 13:22:02 +0000 (15:22 +0200)
commit6514dc380d35570ef8b0cf107d388fe3169cca11
tree9dfd94b224b6ed16dae5b7fe99a96508aa94a23a
parent3a2936dedd207b99c64bf1507a62a9ae44114220
kvm: nVMX: Use nested_run_pending rather than from_vmentry

When saving a vCPU's nested state, the vmcs02 is discarded. Only the
shadow vmcs12 is saved. The shadow vmcs12 contains all of the
information needed to reconstruct an equivalent vmcs02 on restore, but
we have to be able to deal with two contexts:

1. The nested state was saved immediately after an emulated VM-entry,
   before the vmcs02 was ever launched.

2. The nested state was saved some time after the first successful
   launch of the vmcs02.

Though it's an implementation detail rather than an architected bit,
vmx->nested_run_pending serves to distinguish between these two
cases. Hence, we save it as part of the vCPU's nested state. (Yes,
this is ugly.)

Even when restoring from a checkpoint, it may be necessary to build
the vmcs02 as if prepare_vmcs02 was called from nested_vmx_run. So,
the 'from_vmentry' argument should be dropped, and
vmx->nested_run_pending should be consulted instead. The nested state
restoration code then has to set vmx->nested_run_pending prior to
calling prepare_vmcs02. It's important that the restoration code set
vmx->nested_run_pending anyway, since the flag impacts things like
interrupt delivery as well.

Fixes: cf8b84f48a59 ("kvm: nVMX: Prepare for checkpointing L2 state")
Signed-off-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
arch/x86/kvm/vmx.c