aboutsummaryrefslogtreecommitdiff
path: root/tools/testing/selftests/kvm/lib/sparsebit.c
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2021-09-20 17:03:01 -0700
committerPaolo Bonzini <pbonzini@redhat.com>2021-09-30 04:27:07 -0400
commit06692e4b8055cc0c6b136fa7df77221ae9639e97 (patch)
treedd703fa8b5715e345db0e7a324b4cfa4aa7f4fc2 /tools/testing/selftests/kvm/lib/sparsebit.c
parentd06567353e129b460978353cbe2210c23467d6f8 (diff)
KVM: VMX: Move RESET emulation to vmx_vcpu_reset()
Move vCPU RESET emulation, including initializating of select VMCS state, to vmx_vcpu_reset(). Drop the open coded "vCPU load" sequence, as ->vcpu_reset() is invoked while the vCPU is properly loaded (which is kind of the point of ->vcpu_reset()...). Hopefully KVM will someday expose a dedicated RESET ioctl(), and in the meantime separating "create" from "RESET" is a nice cleanup. Deferring VMCS initialization is effectively a nop as it's impossible to safely access the VMCS between the current call site and its new home, as both the vCPU and the pCPU are put immediately after init_vmcs(), i.e. the VMCS isn't guaranteed to be loaded. Note, task preemption is not a problem as vmx_sched_in() _can't_ touch the VMCS as ->sched_in() is invoked before the vCPU, and thus VMCS, is reloaded. I.e. the preemption path also can't consume VMCS state. Cc: Reiji Watanabe <reijiw@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210921000303.400537-9-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'tools/testing/selftests/kvm/lib/sparsebit.c')
0 files changed, 0 insertions, 0 deletions