diff options
author | Sean Christopherson <seanjc@google.com> | 2021-09-20 17:03:01 -0700 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2021-09-30 04:27:07 -0400 |
commit | 06692e4b8055cc0c6b136fa7df77221ae9639e97 (patch) | |
tree | dd703fa8b5715e345db0e7a324b4cfa4aa7f4fc2 /tools/testing/selftests/kvm/lib/sparsebit.c | |
parent | d06567353e129b460978353cbe2210c23467d6f8 (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