| Message ID | d730b06b851d5c502850509d4cf868ed618d10d8.1720501197.git.Sergiy_Kibrik@epam.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | x86: make CPU virtualisation support configurable | expand |
On 09.07.2024 07:54, Sergiy Kibrik wrote: > As we now have SVM/VMX config options for enabling/disabling these features > completely in the build, we need some build-time checks to ensure that vmx/svm > code can be used and things compile. Macros cpu_has_{svm,vmx} used to be doing > such checks at runtime, however they do not check if SVM/VMX support is > enabled in the build. > > Also cpu_has_{svm,vmx} can potentially be called from non-{VMX,SVM} build > yet running on {VMX,SVM}-enabled CPU, so would correctly indicate that VMX/SVM > is indeed supported by CPU, but code to drive it can't be used. > > New routines using_{vmx,svm}() indicate that both CPU _and_ build provide > corresponding technology support, while cpu_has_{vmx,svm} still remains for > informational runtime purpose, just as their naming suggests. > > These new helpers are used right away in several sites, namely guard calls to > start_nested_{svm,vmx} and start_{svm,vmx} to fix a build when VMX=n or SVM=n. > > Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 7f4b627b1f..057c61b4c3 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -155,9 +155,9 @@ static int __init cf_check hvm_enable(void) { const struct hvm_function_table *fns = NULL; - if ( cpu_has_vmx ) + if ( using_vmx() ) fns = start_vmx(); - else if ( cpu_has_svm ) + else if ( using_svm() ) fns = start_svm(); if ( fns == NULL ) diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c index 451c4da6d4..5009167372 100644 --- a/xen/arch/x86/hvm/nestedhvm.c +++ b/xen/arch/x86/hvm/nestedhvm.c @@ -155,9 +155,9 @@ static int __init cf_check nestedhvm_setup(void) * done, so that if (for example) HAP is disabled, nested virt is * disabled as well. */ - if ( cpu_has_vmx ) + if ( using_vmx() ) start_nested_vmx(&hvm_funcs); - else if ( cpu_has_svm ) + else if ( using_svm() ) start_nested_svm(&hvm_funcs); return 0; diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h index 34824af6df..2927a2ad6c 100644 --- a/xen/arch/x86/include/asm/hvm/hvm.h +++ b/xen/arch/x86/include/asm/hvm/hvm.h @@ -363,6 +363,16 @@ int hvm_copy_context_and_params(struct domain *dst, struct domain *src); int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value); +static inline bool using_vmx(void) +{ + return IS_ENABLED(CONFIG_VMX) && cpu_has_vmx; +} + +static inline bool using_svm(void) +{ + return IS_ENABLED(CONFIG_SVM) && cpu_has_svm; +} + #ifdef CONFIG_HVM #define hvm_get_guest_tsc(v) hvm_get_guest_tsc_fixed(v, 0)
As we now have SVM/VMX config options for enabling/disabling these features completely in the build, we need some build-time checks to ensure that vmx/svm code can be used and things compile. Macros cpu_has_{svm,vmx} used to be doing such checks at runtime, however they do not check if SVM/VMX support is enabled in the build. Also cpu_has_{svm,vmx} can potentially be called from non-{VMX,SVM} build yet running on {VMX,SVM}-enabled CPU, so would correctly indicate that VMX/SVM is indeed supported by CPU, but code to drive it can't be used. New routines using_{vmx,svm}() indicate that both CPU _and_ build provide corresponding technology support, while cpu_has_{vmx,svm} still remains for informational runtime purpose, just as their naming suggests. These new helpers are used right away in several sites, namely guard calls to start_nested_{svm,vmx} and start_{svm,vmx} to fix a build when VMX=n or SVM=n. Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> CC: Jan Beulich <jbeulich@suse.com> --- changes in v4: - make using_{vmx,svm} static inline functions instead of macros - squash patch with 2 other patches where using_{vmx,svm} are being used - changed patch description changes in v3: - introduce separate macros instead of modifying behaviour of cpu_has_{vmx,svm} --- xen/arch/x86/hvm/hvm.c | 4 ++-- xen/arch/x86/hvm/nestedhvm.c | 4 ++-- xen/arch/x86/include/asm/hvm/hvm.h | 10 ++++++++++ 3 files changed, 14 insertions(+), 4 deletions(-)