Re: [PATCH 1/2] kbuild: change tool coverage variables to take the path relative to $(obj)

[Sean Christopherson <seanjc@google.com>]

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@kernel.org>
> ---
> 
>  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@google.com>