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 macros using_{vmx,svm} indicates 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.

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
CC: Jan Beulich <jbeulich@suse.com>
---
Here I've followed Jan's suggestion on not touching cpu_has_{vmx,svm} but
adding separate macros for solving build problems, and then using these
where required.
---
changes in v3:
 - introduce separate macros instead of modifying behaviour of cpu_has_{vmx,svm}
---
 xen/arch/x86/include/asm/hvm/hvm.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index 2ebea1a92c..778b93df5c 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -26,6 +26,9 @@ extern bool opt_hvm_fep;
 #define opt_hvm_fep 0
 #endif
 
+#define using_vmx ( IS_ENABLED(CONFIG_VMX) && cpu_has_vmx )
+#define using_svm ( IS_ENABLED(CONFIG_SVM) && cpu_has_svm )
+
 /* Interrupt acknowledgement sources. */
 enum hvm_intsrc {
     hvm_intsrc_none,
-- 
2.25.1

On 03.06.2024 13:16, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -26,6 +26,9 @@ extern bool opt_hvm_fep;
>  #define opt_hvm_fep 0
>  #endif
>  
> +#define using_vmx ( IS_ENABLED(CONFIG_VMX) && cpu_has_vmx )
> +#define using_svm ( IS_ENABLED(CONFIG_SVM) && cpu_has_svm )

Btw, having seen a number of uses by now: Can we consider making these at
least function-like macros (with no arguments), if not inline functions?
Imo that'll make use sites look more "natural".

Jan

On 03.06.2024 13:16, 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 macros using_{vmx,svm} indicates 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.
> 
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> CC: Jan Beulich <jbeulich@suse.com>
> ---
> Here I've followed Jan's suggestion on not touching cpu_has_{vmx,svm} but
> adding separate macros for solving build problems, and then using these
> where required.

As an isolated change this then may want expressing via Suggested-by:.
However, I question whether these wouldn't better be introduced
together with their (first) uses (and then perhaps no such tag).

> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -26,6 +26,9 @@ extern bool opt_hvm_fep;
>  #define opt_hvm_fep 0
>  #endif
>  
> +#define using_vmx ( IS_ENABLED(CONFIG_VMX) && cpu_has_vmx )
> +#define using_svm ( IS_ENABLED(CONFIG_SVM) && cpu_has_svm )

Nit: Stray blanks immediately next to the parentheses.

Jan