summaryrefslogtreecommitdiff
path: root/arch/alpha
diff options
context:
space:
mode:
authorJim Mattson <jmattson@google.com>2018-04-26 16:09:12 -0700
committerRadim Krčmář <rkrcmar@redhat.com>2018-05-23 15:22:02 +0200
commit6514dc380d35570ef8b0cf107d388fe3169cca11 (patch)
tree9dfd94b224b6ed16dae5b7fe99a96508aa94a23a /arch/alpha
parent3a2936dedd207b99c64bf1507a62a9ae44114220 (diff)
downloadlinux-6514dc380d35570ef8b0cf107d388fe3169cca11.tar.gz
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>
Diffstat (limited to 'arch/alpha')
0 files changed, 0 insertions, 0 deletions