| Message ID | 9860c4b497038abda71084ea3bce698eab3b277c.1717410850.git.Sergiy_Kibrik@epam.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: make cpu virtualization support configurable | expand |
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
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
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,
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(+)