Re: [PATCH v7 11/23] KVM: arm64: Share arm64 code with s390

[Steffen Eiden <seiden@linux.ibm.com>]

On Tue, Sep 01, 2026 at 09:13:56AM +0100, Marc Zyngier wrote:
> On Mon, 31 Aug 2026 15:47:48 +0100,
> Steffen Eiden <seiden@linux.ibm.com> wrote:
> > 
> > Mark functions that s390 can use to implement arm on s390 as shared
> > functions.
> > 
> > No functional change.
> > 
> > Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
> > ---
> >  arch/arm64/kvm/arm.c         | 3 +++
> >  arch/arm64/kvm/guest.c       | 6 ++++++
> >  arch/arm64/kvm/handle_exit.c | 6 ++++++
> >  arch/arm64/kvm/mmio.c        | 2 ++
> >  4 files changed, 17 insertions(+)
> > 
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index 8b080804bc90..6b92a3c1d490 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -1603,6 +1603,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)
> >  {
> > @@ -1656,6 +1657,8 @@ static bool kvm_vcpu_init_changed(struct kvm_vcpu *vcpu,
> >  			     KVM_VCPU_MAX_FEATURES);
> >  }
> >  
> > +#endif /* ARM64_S390_COMMON */
> > +
> >  static int kvm_setup_vcpu(struct kvm_vcpu *vcpu)
> >  {
> >  	struct kvm *kvm = vcpu->kvm;
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index 773f6c8e5026..6ca5a9f357cd 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -62,6 +62,7 @@ const struct kvm_stats_header kvm_vcpu_stats_header = {
> >  		       sizeof(kvm_vcpu_stats_desc),
> >  };
> >  
> > +#ifdef ARM64_S390_COMMON
> >  static bool core_reg_offset_is_vreg(u64 off)
> >  {
> >  	return off >= KVM_REG_ARM_CORE_REG(fp_regs.vregs) &&
> > @@ -306,6 +307,8 @@ static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> >  	return err;
> >  }
> >  
> > +#endif /* ARM64_S390_COMMON */
> > +
> >  #define vq_word(vq) (((vq) - SVE_VQ_MIN) / 64)
> >  #define vq_mask(vq) ((u64)1 << ((vq) - SVE_VQ_MIN) % 64)
> >  #define vq_present(vqs, vq) (!!((vqs)[vq_word(vq)] & vq_mask(vq)))
> > @@ -543,6 +546,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)
> >  {
> > @@ -591,6 +595,8 @@ static unsigned long num_core_regs(const struct kvm_vcpu *vcpu)
> >  	return copy_core_reg_indices(vcpu, NULL);
> >  }
> >  
> > +#endif /* ARM64_S390_COMMON */
> > +
> >  static unsigned long num_sve_regs(const struct kvm_vcpu *vcpu)
> >  {
> >  	const unsigned int slices = vcpu_sve_slices(vcpu);
> > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> > index db37678dcb05..6e59a7b12d40 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)
> >  {
> >  	u64 esr = kvm_vcpu_get_esr(vcpu);
> > @@ -224,6 +225,8 @@ static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu)
> >  	return 1;
> >  }
> >  
> > +#endif /* ARM64_S390_COMMON */
> > +
> >  /*
> >   * Guest access to SVE registers should be routed to this handler only
> >   * when the system doesn't support SVE.
> > @@ -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)
> >  {
> >  	u64 esr = kvm_vcpu_get_esr(vcpu);
> > @@ -439,6 +443,8 @@ static int handle_trap_exceptions(struct kvm_vcpu *vcpu)
> >  	return handled;
> >  }
> >  
> > +#endif /* ARM64_S390_COMMON */
> 
> Why the exit handler, and not the EC handlers aside from the UNKNOWN
> one? Yes, you probably aren't there yet in this series, but I can tell
> you are going to add more and more of these.
> 
> But the EC array is absolutely architectural, and there is no good
> reason to maintain your own.
> 
> So instead of this, why not keep the EC array altogether, and
> implement stubs for the ECs you don't support?
> 
> 	M.
> 

There was no specific reasson to define our own EC array as far as I
remember. I will try reusing the array and find out if there are any
issues with that. But I do not expect any. 

I assume the stubs probably just forward to handle_unknown_ec, or do you
have a different suggestion?


	Steffen