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/perf/scripts/python/export-to-sqlite.py | |
| parent | KVM: VMX: Drop explicit zeroing of MSR guest values at vCPU creation (diff) | |
| download | linux-06692e4b8055cc0c6b136fa7df77221ae9639e97.tar.gz linux-06692e4b8055cc0c6b136fa7df77221ae9639e97.zip | |
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/perf/scripts/python/export-to-sqlite.py')
0 files changed, 0 insertions, 0 deletions
