Linux s390 Architecture development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Steffen Eiden" <seiden@linux.ibm.com>
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvmarm@lists.linux.dev,
	"Marc Zyngier" <maz@kernel.org>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	kvm@vger.kernel.org, "Oliver Upton" <oupton@kernel.org>
Subject: Re: [PATCH v4 08/27] KVM: arm64: Prepare sharing arm64 code with s390
Date: Mon, 06 Jul 2026 09:21:46 +0000	[thread overview]
Message-ID: <20260706092146.A69BC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706085229.979525-9-seiden@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The patch misuses C preprocessor `#ifdef` directives to exclude tracepoints, resulting in catastrophic syntax errors because it leaves statements in the global scope.
- [Low] Critical ARM64 functions and definitions are wrapped in `#ifdef ARM64_S390_COMMON`, stripping them from standard ARM64 builds and causing undefined reference errors because their callers remain unconditionally compiled.
--

commit 651f0f9137d42f2814e4612c746de86e829e6666
Author: Steffen Eiden <seiden@linux.ibm.com>

KVM: arm64: Prepare sharing arm64 code with s390

This commit marks functions that s390 can use to implement arm on s390 as
shared functions, without introducing functional changes.

> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 50adfff75be82..c992308b2dceb 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1580,6 +1580,7 @@ static unsigned long system_supported_vcpu_features(void)
>  	return features;
>  }
>  
> +#ifdef ARM64_S390_COMMON
>  static int kvm_vcpu_init_check_features(struct kvm_vcpu *vcpu,
>  					const struct kvm_vcpu_init *init)
>  {

[Severity: Low]
Will this cause undefined reference errors on standard ARM64 builds? 

The caller of kvm_vcpu_init_check_features() remains unconditionally compiled,
so the symbol will be missing when ARM64_S390_COMMON is not defined.

> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index b01d6622b8720..5a202cfd27bcb 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -543,6 +543,7 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>  	return -EINVAL;
>  }
>  
> +#ifdef ARM64_S390_COMMON
>  static int copy_core_reg_indices(const struct kvm_vcpu *vcpu,
>  				 u64 __user *uindices)
>  {

[Severity: Low]
Does this missing symbol cause a link failure for kvm_arm_copy_reg_indices()?
The function is compiled out here, but the caller isn't.

> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 54aedf93c78b6..d511af145ee6a 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -213,6 +213,7 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu)
>  	return 0;
>  }
>  
> +#ifdef ARM64_S390_COMMON
>  static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu)
>  {

[Severity: Low]
Will this lead to an undefined reference? 

kvm_handle_unknown_ec() is conditionally removed here, but it remains
referenced in the unconditionally compiled arm_exit_handlers array.

[ ... ]

> @@ -404,6 +407,7 @@ static exit_handle_fn arm_exit_handlers[] = {
>  	[ESR_ELx_EC_GCS]	= kvm_handle_gcs,
>  };
>  
> +#ifdef ARM64_S390_COMMON
>  static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
>  {

[Severity: Low]
Is it intentional to compile out kvm_get_exit_handler() and
handle_trap_exceptions()? 

The handle_exit() caller relies on them unconditionally, which may cause a
build failure.

> diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c
> index e2285ed8c91de..876d56dd5b640 100644
> --- a/arch/arm64/kvm/mmio.c
> +++ b/arch/arm64/kvm/mmio.c

[ ... ]

> @@ -135,8 +136,11 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu)
>  		if (!kvm_vcpu_dabt_issf(vcpu))
>  			data = data & 0xffffffff;
>  
> +#endif /* ARM64_S390_COMMON */
>  		trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr,
>  			       &data);
> +		//TODO  tracing
> +#ifdef ARM64_S390_COMMON
>  		data = vcpu_data_host_to_guest(vcpu, data, len);
>  		vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data);
>  	}

[Severity: Low]
Does this inverted preprocessor logic break the build on standard ARM64?

Since kvm_handle_mmio_return() starts inside an ifdef ARM64_S390_COMMON block,
placing an endif here exposes the trace_kvm_mmio() call to the global scope
when the flag is not set, resulting in invalid C syntax.

[ ... ]

> @@ -171,8 +175,11 @@ int io_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa)
>  	 * though, so directly deliver an exception to the guest.
>  	 */
>  	if (!kvm_vcpu_dabt_isvalid(vcpu)) {
> +#endif /* ARM64_S390_COMMON */
>  		trace_kvm_mmio_nisv(*vcpu_pc(vcpu), esr,
>  				    kvm_vcpu_get_hfar(vcpu), fault_ipa);
> +		//TODO tracing
> +#ifdef ARM64_S390_COMMON
>  
>  		if (vcpu_is_protected(vcpu))
>  			return kvm_inject_sea_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));

[Severity: Low]
Similar to the issue above, does this leave trace_kvm_mmio_nisv() in the
global scope and cause syntax errors when ARM64_S390_COMMON is undefined?

> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index b963fd975aaca..faab6f03f3655 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -34,6 +34,7 @@
>  static u32 __ro_after_init kvm_ipa_limit;
>  unsigned int __ro_after_init kvm_host_sve_max_vl;
>  
> +#ifdef ARM64_S390_COMMON
>  /*
>   * ARMv8 Reset Values
>   */
> @@ -46,6 +47,8 @@ unsigned int __ro_after_init kvm_host_sve_max_vl;
>  #define VCPU_RESET_PSTATE_SVC	(PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
>  				 PSR_AA32_I_BIT | PSR_AA32_F_BIT)
>  
> +#endif /* ARM64_S390_COMMON */

[Severity: Low]
Could stripping out these reset value macros cause compilation to fail? 

They appear to be used in unconditional kvm_reset_vcpu() initialization logic.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706085229.979525-1-seiden@linux.ibm.com?part=8

  reply	other threads:[~2026-07-06  9:21 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06  8:52 [PATCH v4 00/27] KVM: s390: Introduce arm64 KVM Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 01/27] VFIO: take reference to the KVM module Steffen Eiden
2026-07-06  9:12   ` sashiko-bot
2026-07-06 19:53   ` Jason Gunthorpe
2026-07-06 21:12     ` Sean Christopherson
2026-07-06  8:52 ` [PATCH v4 02/27] KVM, vfio: remove symbol_get(kvm_get_kvm_safe) from vfio Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 03/27] KVM, vfio: remove symbol_get(kvm_put_kvm) " Steffen Eiden
2026-07-06  9:25   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 04/27] KVM: Make device name configurable Steffen Eiden
2026-07-06  9:14   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 05/27] KVM: Remove KVM_MMIO as config option Steffen Eiden
2026-07-06 20:53   ` Marc Zyngier
2026-07-06  8:52 ` [PATCH v4 06/27] arm64: Use proper include variant Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 07/27] arm64: Prepare sharing arm64 headers with s390 Steffen Eiden
2026-07-06 21:22   ` Marc Zyngier
2026-07-06  8:52 ` [PATCH v4 08/27] KVM: arm64: Prepare sharing arm64 code " Steffen Eiden
2026-07-06  9:21   ` sashiko-bot [this message]
2026-07-06 21:28   ` Marc Zyngier
2026-07-06  8:52 ` [PATCH v4 09/27] KVM: arm64: Access elements of vcpu_gp_regs individually Steffen Eiden
2026-07-06 17:44   ` Marc Zyngier
2026-07-06  8:52 ` [PATCH v4 10/27] KVM: arm64: Refactor core-reset into a separate function Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 11/27] s390: Use arm64 headers Steffen Eiden
2026-07-06  9:31   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 12/27] KVM: s390: Use arm64 code Steffen Eiden
2026-07-06  9:26   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 13/27] KVM: s390: Prepare KVM/s390 for a second KVM module Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 14/27] KVM: s390: Move s390 kvm code into a subdirectory Steffen Eiden
2026-07-06  9:35   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 15/27] KVM: S390: Prepare gmap for a second KVM implementation Steffen Eiden
2026-07-06  9:36   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 16/27] KVM: s390: gmap: Refactor storage key and CMMA code into separate files Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 17/27] KVM: s390: Refactor prefix handling into a separate file Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 18/27] KVM: s390: Prepare kvm-s390 for a second kvm module Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 19/27] s390: Introduce Start Arm Execution instruction Steffen Eiden
2026-07-06 11:17   ` Janosch Frank
2026-07-06 11:30     ` Christian Borntraeger
2026-07-06 11:58       ` Steffen Eiden
2026-07-06 11:53     ` Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 20/27] KVM: s390: arm64: Introduce host definitions Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 21/27] s390/hwcaps: Report SAE support as hwcap Steffen Eiden
2026-07-06 11:50   ` Janosch Frank
2026-07-06  8:52 ` [PATCH v4 22/27] KVM: s390: Add basic arm64 kvm module Steffen Eiden
2026-07-06  9:51   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 23/27] KVM: s390: arm64: Implement required functions Steffen Eiden
2026-07-06  9:55   ` sashiko-bot
2026-07-06 12:15   ` Janosch Frank
2026-07-06 20:35   ` Marc Zyngier
2026-07-06  8:52 ` [PATCH v4 24/27] KVM: s390: arm64: Implement vm/vcpu create destroy Steffen Eiden
2026-07-06 10:04   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 25/27] KVM: s390: arm64: Implement vCPU IOCTLs Steffen Eiden
2026-07-06 10:16   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 26/27] KVM: s390: arm64: Implement basic page fault handler Steffen Eiden
2026-07-06 10:03   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 27/27] KVM: s390: arm64: Enable KVM_ARM64 config and Kbuild Steffen Eiden
2026-07-06 10:07   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260706092146.A69BC1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-s390@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=seiden@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox