On Sat, Feb 17, 2024, Masahiro Yamada wrote:
> To maintain the current behavior, I made adjustments to two Makefiles:
>
> - arch/x86/entry/vdso/Makefile, which compiles vclock_gettime.o and
> vdso32/vclock_gettime.o
>
> - arch/x86/kvm/Makefile, which compiles vmx/vmenter.o and svm/vmenter.o
>
> Signed-off-by: Masahiro Yamada <masahiroy@xxxxxxxxxx>
> ---
>
> arch/x86/entry/vdso/Makefile | 2 ++
> arch/x86/kvm/Makefile | 3 ++-
> scripts/Makefile.build | 2 +-
> scripts/Makefile.lib | 16 ++++++++--------
> 4 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index 7a97b17f28b7..148adfdb2325 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -9,7 +9,9 @@ include $(srctree)/lib/vdso/Makefile
> # Sanitizer runtimes are unavailable and cannot be linked here.
> KASAN_SANITIZE := n
> KMSAN_SANITIZE_vclock_gettime.o := n
> +KMSAN_SANITIZE_vdso32/vclock_gettime.o := n
> KMSAN_SANITIZE_vgetcpu.o := n
> +KMSAN_SANITIZE_vdso32/vgetcpu.o := n
>
> UBSAN_SANITIZE := n
> KCSAN_SANITIZE := n
> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
> index 475b5fa917a6..a88bb14266b6 100644
> --- a/arch/x86/kvm/Makefile
> +++ b/arch/x86/kvm/Makefile
> @@ -4,7 +4,8 @@ ccflags-y += -I $(srctree)/arch/x86/kvm
> ccflags-$(CONFIG_KVM_WERROR) += -Werror
>
> ifeq ($(CONFIG_FRAME_POINTER),y)
> -OBJECT_FILES_NON_STANDARD_vmenter.o := y
> +OBJECT_FILES_NON_STANDARD_vmx/vmenter.o := y
> +OBJECT_FILES_NON_STANDARD_svm/vmenter.o := y
> endif
I'm 99% certain only svm/vmenter.S "needs" to be compiled with OBJECT_FILES_NON_STANDARD,
and that vmx/vmenter.S got caught in the crossfire off commit commit 7f4b5cde2409
("kvm: Disable objtool frame pointer checking for vmenter.S").
"Needs" in quotes because I don't see any reason when __svm_vcpu_run() can't play
the same games as __vmx_vcpu_run() to make stack validation happy, and
__svm_sev_es_vcpu_run() flat out shouldn't be touching RBP.
I'll throw together a series to (hopefully) remove OBJECT_FILES_NON_STANDARD
completely.
But for this patch/series, I think it makes sense to do a 1:1 conversion. That'll
make it much more straightforward to resolve the eventual conflict, assuming I am
successful in dropping OBJECT_FILES_NON_STANDARD.
Which is a very long-winded way of saying:
Acked-by: Sean Christopherson <seanjc@xxxxxxxxxx>
