All of lore.kernel.org
 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: 76+ 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-13 15:33       ` 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
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-13 15:42       ` 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-10  9:22   ` Christian Borntraeger
2026-07-10 10:51     ` Steffen Eiden
2026-07-13 16:38   ` Claudio Imbrenda
2026-07-14 10:40     ` 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-13 15:46       ` Marc Zyngier
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.