Linux s390 Architecture development
 help / color / mirror / Atom feed
From: Steffen Eiden <seiden@linux.ibm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Andreas Grapentin <gra@linux.ibm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	David Hildenbrand <david@kernel.org>,
	Friedrich Welter <fritz@linux.ibm.com>,
	Gautam Gala <ggala@linux.ibm.com>,
	Hariharan Mari <hari55@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Hendrik Brueckner <brueckner@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Joey Gouly <joey.gouly@arm.com>, Nico Boehr <nrb@linux.ibm.com>,
	Nina Schoetterl-Glausch <oss@nina.schoetterlglausch.eu>,
	Oliver Upton <oupton@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>, Will Deacon <will@kernel.org>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v4 07/27] arm64: Prepare sharing arm64 headers with s390
Date: Fri, 10 Jul 2026 11:54:26 +0200	[thread overview]
Message-ID: <20260710095426.984749-F-seiden@linux.ibm.com> (raw)
In-Reply-To: <878q7n7qzi.wl-maz@kernel.org>

On Mon, Jul 06, 2026 at 10:22:41PM +0100, Marc Zyngier wrote:
> On Mon, 06 Jul 2026 09:52:07 +0100,
> Steffen Eiden <seiden@linux.ibm.com> wrote:
> > 
> > Prepare the sharing of arm64 headers with s390 by marking the shared
> > regions or add a comment that the whole file is shared.
> > The regions are marked with:
> > 
> >  #define ARM64_S390_COMMON
> > 
> >  /* insert shared definitions here */
> > 
> >  #endif /* ARM64_S390_COMMON */
> > 
> > The preprocessor symbol ARM64_S390_COMMON is always defined for arm64.
> > Reduce the include scope where possible and beneficial for s390.
> > No functional change.
> > 
> > Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
> > ---
> >  arch/arm64/Makefile                  |  2 ++
> >  arch/arm64/include/asm/brk-imm.h     |  1 +
> >  arch/arm64/include/asm/esr.h         |  5 +++--
> >  arch/arm64/include/asm/kvm_arm.h     |  6 ++++--
> >  arch/arm64/include/asm/kvm_emulate.h | 19 ++++++++++++++++++
> >  arch/arm64/include/asm/kvm_host.h    | 28 +++++++++++++++++++++++++++
> >  arch/arm64/include/asm/kvm_mmu.h     |  6 ++++++
> >  arch/arm64/include/asm/ptrace.h      |  9 +++++++++
> >  arch/arm64/include/asm/sysreg.h      | 29 +++++++++++++++++++++++++---
> >  9 files changed, 98 insertions(+), 7 deletions(-)
> > 

...

> >  		vcpu_set_flag((v), e);					\
> >  	} while (0)
> >  
> > +#endif /* ARM64_S390_COMMON */
> > +
> 
> It'd be worth looking at an initial patch reorganising this file to
> minimise the number of such markers. This is equally valid for other
> files in this patch.
> 
> [...]
> 

So it is fine if I reorganize files a bit to reduce the number of
markes?
I feared it would not. I will reorganize the files a bit then if this
reduces the number of sections. Also if some thiings are required in a
later series I might alreaddy share the stuff if possible if that
reduces the number of regions.


> > diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> > index 6eae7e7e2a68..b782cae771fe 100644
> > --- a/arch/arm64/include/asm/kvm_mmu.h
> > +++ b/arch/arm64/include/asm/kvm_mmu.h
> > @@ -142,12 +142,15 @@ static __always_inline unsigned long __kern_hyp_va(unsigned long v)
> >  
> >  extern u32 __hyp_va_bits;
> >  
> > +#ifdef ARM64_S390_COMMON
> >  /*
> >   * We currently support using a VM-specified IPA size. For backward
> >   * compatibility, the default IPA size is fixed to 40bits.
> >   */
> >  #define KVM_PHYS_SHIFT	(40)
> >  
> > +#endif /* ARM64_S390_COMMON */
> > +
> >  #define kvm_phys_shift(mmu)		VTCR_EL2_IPA((mmu)->vtcr)
> >  #define kvm_phys_size(mmu)		(_AC(1, ULL) << kvm_phys_shift(mmu))
> >  #define kvm_phys_mask(mmu)		(kvm_phys_size(mmu) - _AC(1, ULL))
> > @@ -178,9 +181,12 @@ void stage2_unmap_vm(struct kvm *kvm);
> >  int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long type);
> >  void kvm_uninit_stage2_mmu(struct kvm *kvm);
> >  void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu);
> > +#ifdef ARM64_S390_COMMON
> >  int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> >  			  phys_addr_t pa, unsigned long size, bool writable);
> 
> This only serves a purpose for GICv2, and I really hope your HW will
> not implement this. You should probably find a way to avoid dragging
> stuff that doesn't make sense on s390.
> 

good catch, I added this as a mistake. It was a leftover from the early
days.


...

> > +#ifdef ARM64_S390_COMMON
> > +
> >  /*
> >   * Instructions for modifying PSTATE fields.
> >   * As per Arm ARM for v8-A, Section "C.5.1.3 op0 == 0b00, architectural hints,
> > @@ -91,8 +99,6 @@
> >   */
> >  #define pstate_field(op1, op2)		((op1) << Op1_shift | (op2) << Op2_shift)
> >  #define PSTATE_Imm_shift		CRm_shift
> > -#define ENCODE_PSTATE(x, r)		(0xd500401f | PSTATE_ ## r | ((!!x) << PSTATE_Imm_shift))
> > -#define SET_PSTATE(x, r)		__emit_inst(ENCODE_PSTATE(x, r))
> >  
> >  #define PSTATE_PAN			pstate_field(0, 4)
> >  #define PSTATE_UAO			pstate_field(0, 3)
> > @@ -100,6 +106,11 @@
> >  #define PSTATE_DIT			pstate_field(3, 2)
> >  #define PSTATE_TCO			pstate_field(3, 4)
> >  
> > +#endif /* ARM64_S390_COMMON */
> > +
> > +#define ENCODE_PSTATE(x, r)		(0xd500401f | PSTATE_ ## r | ((!!x) << PSTATE_Imm_shift))
> > +#define SET_PSTATE(x, r)		__emit_inst(ENCODE_PSTATE(x, r))
> > +
> >  #define SET_PSTATE_PAN(x)		SET_PSTATE((x), PAN)
> >  #define SET_PSTATE_UAO(x)		SET_PSTATE((x), UAO)
> >  #define SET_PSTATE_SSBS(x)		SET_PSTATE((x), SSBS)
> > @@ -123,6 +134,8 @@
> >  #define GSB_SYS_BARRIER_INSN		__SYS_BARRIER_INSN(1, 0, 12, 0, 0, 31)
> >  #define GSB_ACK_BARRIER_INSN		__SYS_BARRIER_INSN(1, 0, 12, 0, 1, 31)
> 
> What is the reason to avoid dragging these definitions? They seem
> extremely similar to the rest.
> 

They emit arm64 instructions, dont they?

> >
> > +#ifdef ARM64_S390_COMMON
> > +
> >  /* Data cache zero operations */
> >  #define SYS_DC_ISW			sys_insn(1, 0, 7, 6, 2)
> >  #define SYS_DC_IGSW			sys_insn(1, 0, 7, 6, 4)
> > @@ -835,6 +848,8 @@
> >  #define SCTLR_ELx_A	 (BIT(1))
> >  #define SCTLR_ELx_M	 (BIT(0))
> >  
> > +#endif /* ARM64_S390_COMMON */
> > +
> >  #ifdef CONFIG_CPU_BIG_ENDIAN
> >  #define ENDIAN_SET_EL2		SCTLR_ELx_EE
> >  #else
> > @@ -869,6 +884,8 @@
> >  	 SCTLR_EL1_LSMAOE | SCTLR_EL1_nTLSMD | SCTLR_EL1_EIS   | \
> >  	 SCTLR_EL1_TSCXT  | SCTLR_EL1_EOS)
> >  
> > +#ifdef ARM64_S390_COMMON
> > +
> >  /* MAIR_ELx memory attributes (used by Linux) */
> >  #define MAIR_ATTR_DEVICE_nGnRnE		UL(0x00)
> >  #define MAIR_ATTR_DEVICE_nGnRE		UL(0x04)
> > @@ -1105,6 +1122,8 @@
> >  #define GICV5_GICR_CDNMIA_TYPE_MASK	GENMASK_ULL(31, 29)
> >  #define GICV5_GICR_CDNMIA_ID_MASK	GENMASK_ULL(23, 0)
> >  
> > +#endif /* ARM64_S390_COMMON */
> > +
> >  #define gicr_insn(insn)			read_sysreg_s(GICV5_OP_GICR_##insn)
> >  #define gic_insn(v, insn)		write_sysreg_s(v, GICV5_OP_GIC_##insn)
> >  
> > @@ -1254,6 +1273,8 @@
> >  	par;								\
> >  })
> >  
> > +#ifdef ARM64_S390_COMMON
> > +
> >  #define SYS_FIELD_VALUE(reg, field, val)	reg##_##field##_##val
> >  
> >  #define SYS_FIELD_GET(reg, field, val)		\
> > @@ -1266,6 +1287,8 @@
> >  		 FIELD_PREP(reg##_##field##_MASK,	\
> >  			    SYS_FIELD_VALUE(reg, field, val))
> >  
> > -#endif
> > +#endif /* ARM64_S390_COMMON */
> > +
> > +#endif /* __ASSEMBLER__ */
> >  
> >  #endif	/* __ASM_SYSREG_H */
> 
> Overall, the fine-grained tagging is a bit hard to read, and there is
> no obvious rationale on why some bits are needed, and not others are
> not.
>

Sometimes the reason that it is not used is that they are not used yet
but will in a later series. I defenitely can add a few more function
that we need right now to reduce the scatter.

> It definitely looks more manageable than the previous iteration, but
> as I said above, it would benefit from a less scattergun approach.
That is great to hear!

I tried to move as little arm code as possible. This is probably the
other extreme compared to the first attempts where I moved everything.
I will try out moving a few functions/defenitions inside the
headers/functions to resuce the scattering.

	Steffen


  reply	other threads:[~2026-07-10  9:54 UTC|newest]

Thread overview: 71+ 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-07  7:39       ` Steffen Eiden
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-10  8:54     ` Steffen Eiden
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-10  9:54     ` Steffen Eiden [this message]
2026-07-06  8:52 ` [PATCH v4 08/27] KVM: arm64: Prepare sharing arm64 code " Steffen Eiden
2026-07-06  9:21   ` sashiko-bot
2026-07-06 21:28   ` Marc Zyngier
2026-07-07  7:20     ` Steffen Eiden
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-10 11:56     ` Steffen Eiden
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-10  9:22   ` Christian Borntraeger
2026-07-10 10:51     ` 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-08 12:33   ` Janosch Frank
2026-07-10  9:29   ` Christian Borntraeger
2026-07-10 12:29     ` Steffen Eiden
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-10 13:40     ` Steffen Eiden
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-07 15:10   ` Marc Zyngier
2026-07-08  6:51     ` Steffen Eiden
2026-07-08  7:36       ` Marc Zyngier
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-08 10:44   ` Marc Zyngier
2026-07-10 14:07     ` Steffen Eiden
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=20260710095426.984749-F-seiden@linux.ibm.com \
    --to=seiden@linux.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=arnd@arndb.de \
    --cc=borntraeger@linux.ibm.com \
    --cc=brueckner@linux.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=david@kernel.org \
    --cc=frankja@linux.ibm.com \
    --cc=fritz@linux.ibm.com \
    --cc=ggala@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=gra@linux.ibm.com \
    --cc=hari55@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=nrb@linux.ibm.com \
    --cc=oss@nina.schoetterlglausch.eu \
    --cc=oupton@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=suzuki.poulose@arm.com \
    --cc=svens@linux.ibm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.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