[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f0b3d3ef960882b34e365bc6fbb97d8df8931efc.camel@redhat.com>
Date: Tue, 12 Jul 2022 14:52:21 +0300
From: Maxim Levitsky <mlevitsk@...hat.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>
Cc: Anirudh Rayabharam <anrayabh@...ux.microsoft.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 08/25] KVM: selftests: Switch to updated eVMCSv1
definition
On Fri, 2022-07-08 at 16:42 +0200, Vitaly Kuznetsov wrote:
> Update Enlightened VMCS definition in selftests from KVM.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
> ---
> .../selftests/kvm/include/x86_64/evmcs.h | 45 +++++++++++++++++--
> 1 file changed, 42 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/include/x86_64/evmcs.h b/tools/testing/selftests/kvm/include/x86_64/evmcs.h
> index 3c9260f8e116..a777711d5474 100644
> --- a/tools/testing/selftests/kvm/include/x86_64/evmcs.h
> +++ b/tools/testing/selftests/kvm/include/x86_64/evmcs.h
> @@ -203,14 +203,25 @@ struct hv_enlightened_vmcs {
> u32 reserved:30;
> } hv_enlightenments_control;
> u32 hv_vp_id;
> -
> + u32 padding32_2;
This is not just an update, this is a fix - I do see that padding field,
in the spec. It is possible that compiler added that padding on its own
to pad everything to 8 bytes though.
> u64 hv_vm_id;
> u64 partition_assist_page;
> u64 padding64_4[4];
> u64 guest_bndcfgs;
> - u64 padding64_5[7];
> + u64 guest_ia32_perf_global_ctrl;
> + u64 guest_ia32_s_cet;
> + u64 guest_ssp;
> + u64 guest_ia32_int_ssp_table_addr;
> + u64 guest_ia32_lbr_ctl;
> + u64 padding64_5[2];
Matches the spec.
> u64 xss_exit_bitmap;
> - u64 padding64_6[7];
> + u64 host_ia32_perf_global_ctrl;
> + u64 encls_exiting_bitmap;
This is swapped here as well, expains why it was not caught in the testing.
> + u64 tsc_multiplier;
> + u64 host_ia32_s_cet;
> + u64 host_ssp;
> + u64 host_ia32_int_ssp_table_addr;
> + u64 padding64_6;
> };
>
> #define HV_VMX_ENLIGHTENED_CLEAN_FIELD_NONE 0
> @@ -656,6 +667,18 @@ static inline int evmcs_vmread(uint64_t encoding, uint64_t *value)
> case VIRTUAL_PROCESSOR_ID:
> *value = current_evmcs->virtual_processor_id;
> break;
> + case HOST_IA32_PERF_GLOBAL_CTRL:
> + *value = current_evmcs->host_ia32_perf_global_ctrl;
> + break;
> + case GUEST_IA32_PERF_GLOBAL_CTRL:
> + *value = current_evmcs->guest_ia32_perf_global_ctrl;
> + break;
> + case ENCLS_EXITING_BITMAP:
> + *value = current_evmcs->encls_exiting_bitmap;
> + break;
> + case TSC_MULTIPLIER:
> + *value = current_evmcs->tsc_multiplier;
> + break;
> default: return 1;
> }
>
> @@ -1169,6 +1192,22 @@ static inline int evmcs_vmwrite(uint64_t encoding, uint64_t value)
> current_evmcs->virtual_processor_id = value;
> current_evmcs->hv_clean_fields &= ~HV_VMX_ENLIGHTENED_CLEAN_FIELD_CONTROL_XLAT;
> break;
> + case HOST_IA32_PERF_GLOBAL_CTRL:
> + current_evmcs->host_ia32_perf_global_ctrl = value;
> + current_evmcs->hv_clean_fields &= ~HV_VMX_ENLIGHTENED_CLEAN_FIELD_HOST_GRP1;
> + break;
> + case GUEST_IA32_PERF_GLOBAL_CTRL:
> + current_evmcs->guest_ia32_perf_global_ctrl = value;
> + current_evmcs->hv_clean_fields &= ~HV_VMX_ENLIGHTENED_CLEAN_FIELD_GUEST_GRP1;
> + break;
> + case ENCLS_EXITING_BITMAP:
> + current_evmcs->encls_exiting_bitmap = value;
> + current_evmcs->hv_clean_fields &= ~HV_VMX_ENLIGHTENED_CLEAN_FIELD_CONTROL_GRP2;
> + break;
> + case TSC_MULTIPLIER:
> + current_evmcs->tsc_multiplier = value;
> + current_evmcs->hv_clean_fields &= ~HV_VMX_ENLIGHTENED_CLEAN_FIELD_CONTROL_GRP2;
> + break;
> default: return 1;
> }
>
Other than bug in the order of host_ia32_perf_global_ctrl/encls_exiting_bitmap, everything else looks fine to me.
So with this bug fixed:
Reviewed-by: Maxim Levitsky <mlevitsk@...hat.com>
Best regards,
Maxim Levitsky
Powered by blists - more mailing lists