Skip to content

Commit b2e02f8

Browse files
vittyvksean-jc
authored andcommitted
KVM: nVMX: Split off helper for emulating VMCLEAR on Hyper-V eVMCS
To avoid overloading handle_vmclear() with Hyper-V specific details and to prepare the code to making Hyper-V emulation optional, create a dedicated nested_evmcs_handle_vmclear() helper. No functional change intended. Suggested-by: Sean Christopherson <seanjc@google.com> Tested-by: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20231205103630.1391318-9-vkuznets@redhat.com Signed-off-by: Sean Christopherson <seanjc@google.com>
1 parent af9d544 commit b2e02f8

1 file changed

Lines changed: 24 additions & 14 deletions

File tree

arch/x86/kvm/vmx/nested.c

Lines changed: 24 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -243,6 +243,29 @@ static inline void nested_release_evmcs(struct kvm_vcpu *vcpu)
243243
}
244244
}
245245

246+
static bool nested_evmcs_handle_vmclear(struct kvm_vcpu *vcpu, gpa_t vmptr)
247+
{
248+
struct vcpu_vmx *vmx = to_vmx(vcpu);
249+
/*
250+
* When Enlightened VMEntry is enabled on the calling CPU we treat
251+
* memory area pointer by vmptr as Enlightened VMCS (as there's no good
252+
* way to distinguish it from VMCS12) and we must not corrupt it by
253+
* writing to the non-existent 'launch_state' field. The area doesn't
254+
* have to be the currently active EVMCS on the calling CPU and there's
255+
* nothing KVM has to do to transition it from 'active' to 'non-active'
256+
* state. It is possible that the area will stay mapped as
257+
* vmx->nested.hv_evmcs but this shouldn't be a problem.
258+
*/
259+
if (!guest_cpuid_has_evmcs(vcpu) ||
260+
!evmptr_is_valid(nested_get_evmptr(vcpu)))
261+
return false;
262+
263+
if (vmx->nested.hv_evmcs && vmptr == vmx->nested.hv_evmcs_vmptr)
264+
nested_release_evmcs(vcpu);
265+
266+
return true;
267+
}
268+
246269
static void vmx_sync_vmcs_host_state(struct vcpu_vmx *vmx,
247270
struct loaded_vmcs *prev)
248271
{
@@ -5286,18 +5309,7 @@ static int handle_vmclear(struct kvm_vcpu *vcpu)
52865309
if (vmptr == vmx->nested.vmxon_ptr)
52875310
return nested_vmx_fail(vcpu, VMXERR_VMCLEAR_VMXON_POINTER);
52885311

5289-
/*
5290-
* When Enlightened VMEntry is enabled on the calling CPU we treat
5291-
* memory area pointer by vmptr as Enlightened VMCS (as there's no good
5292-
* way to distinguish it from VMCS12) and we must not corrupt it by
5293-
* writing to the non-existent 'launch_state' field. The area doesn't
5294-
* have to be the currently active EVMCS on the calling CPU and there's
5295-
* nothing KVM has to do to transition it from 'active' to 'non-active'
5296-
* state. It is possible that the area will stay mapped as
5297-
* vmx->nested.hv_evmcs but this shouldn't be a problem.
5298-
*/
5299-
if (likely(!guest_cpuid_has_evmcs(vcpu) ||
5300-
!evmptr_is_valid(nested_get_evmptr(vcpu)))) {
5312+
if (likely(!nested_evmcs_handle_vmclear(vcpu, vmptr))) {
53015313
if (vmptr == vmx->nested.current_vmptr)
53025314
nested_release_vmcs12(vcpu);
53035315

@@ -5314,8 +5326,6 @@ static int handle_vmclear(struct kvm_vcpu *vcpu)
53145326
vmptr + offsetof(struct vmcs12,
53155327
launch_state),
53165328
&zero, sizeof(zero));
5317-
} else if (vmx->nested.hv_evmcs && vmptr == vmx->nested.hv_evmcs_vmptr) {
5318-
nested_release_evmcs(vcpu);
53195329
}
53205330

53215331
return nested_vmx_succeed(vcpu);

0 commit comments

Comments
 (0)