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
next prev parent 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