From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1349FC43458 for ; Mon, 13 Jul 2026 15:31:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=OU0kBWfYm2e1Vbiw7Vo5mciB2uXRYmNVKqqRWrRTVCo=; b=LCmwHNM7H5E4x+H5EkI3Z2+KlD 9H87g3P3ii0Hjapxv7y4gtrW2Vl/rmAhbLfmKO4dwatNOJ9bsxRW87NKuPHgjQvBMxyKstXmYYkLW H6usRg7Divjiphmdtuy54DlWQe0ffeE2CqC9nZCMXnLpX1SP6+ZK2VefSgWRdJxycFZ+DlztF7AWw cbSGnoB53UKemOmv2+ygPHd37NwpX4AWZJNSgm9po3KGf1p57aOqiGcyEWLgXby6QBnHRdJW3CL0G t06OgQfICG5vb51Hipzx8hS//C18m/ysSnCNNjDqqs3WmLBxO96Tpl9t33H5O+nOQC9Navq0ZoU1V vCHLYWkg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjIcw-00000009nZw-2jwV; Mon, 13 Jul 2026 15:31:26 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjIcv-00000009nZj-0wzS for linux-arm-kernel@lists.infradead.org; Mon, 13 Jul 2026 15:31:25 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id EB243406DE; Mon, 13 Jul 2026 15:31:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA0CE1F000E9; Mon, 13 Jul 2026 15:31:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783956684; bh=OU0kBWfYm2e1Vbiw7Vo5mciB2uXRYmNVKqqRWrRTVCo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=R1sjbB13BZ3Mn0ZIwwmn5bjUrr3bXrQOczCT1xn1qei/TKv8hjzqLbIGFNchaa2cz q8Hw/XnZlSQWMtMq0ndTlVcNR+0PRHbnG4USdth8WMzXqu2hV21Yvks5fFqosdmDmz RQ5Z4WdNz0w1P6404eF2/A0DJtxvdyB+97oFezHC3IKfpXzFk1qlbIpmNO+AJnkqzl 6aYju/mmpOkYLzscf1KYP7M32eptqvA624cG3QQpUrRW8nEPfuCHAPuEhnUjChXNSq 5OCH7m0bBJV9FSW9qKX3slNiduXaXDrOdPHL4Uev65n7afFW134GKLaCvi0vpowfW6 9JZt5D9LsI+2Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wjIcs-00000004Y7n-3dqA; Mon, 13 Jul 2026 15:31:22 +0000 Date: Mon, 13 Jul 2026 16:33:11 +0100 Message-ID: <87bjca6h1k.wl-maz@kernel.org> From: Marc Zyngier To: Steffen Eiden 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 , Andreas Grapentin , Arnd Bergmann , Catalin Marinas , Christian Borntraeger , Claudio Imbrenda , David Hildenbrand , Friedrich Welter , Gautam Gala , Hariharan Mari , Heiko Carstens , Hendrik Brueckner , Ilya Leoshkevich , Janosch Frank , Joey Gouly , Nico Boehr , Nina Schoetterl-Glausch , Oliver Upton , Paolo Bonzini , Suzuki K Poulose , Sven Schnelle , Ulrich Weigand , Vasily Gorbik , Will Deacon , Zenghui Yu Subject: Re: [PATCH v4 07/27] arm64: Prepare sharing arm64 headers with s390 In-Reply-To: <20260710095426.984749-F-seiden@linux.ibm.com> References: <20260706085229.979525-1-seiden@linux.ibm.com> <20260706085229.979525-8-seiden@linux.ibm.com> <878q7n7qzi.wl-maz@kernel.org> <20260710095426.984749-F-seiden@linux.ibm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: seiden@linux.ibm.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, agordeev@linux.ibm.com, gra@linux.ibm.com, arnd@arndb.de, catalin.marinas@arm.com, borntraeger@linux.ibm.com, imbrenda@linux.ibm.com, david@kernel.org, fritz@linux.ibm.com, ggala@linux.ibm.com, hari55@linux.ibm.com, hca@linux.ibm.com, brueckner@linux.ibm.com, iii@linux.ibm.com, frankja@linux.ibm.com, joey.gouly@arm.com, nrb@linux.ibm.com, oss@nina.schoetterlglausch.eu, oupton@kernel.org, pbonzini@redhat.com, suzuki.poulose@arm.com, svens@linux.ibm.com, Ulrich.Weigand@de.ibm.com, gor@linux.ibm.com, will@kernel.org, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 10 Jul 2026 10:54:26 +0100, Steffen Eiden wrote: > > On Mon, Jul 06, 2026 at 10:22:41PM +0100, Marc Zyngier wrote: > > On Mon, 06 Jul 2026 09:52:07 +0100, > > Steffen Eiden 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 > > > --- > > > 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? Within reason, yes. > 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. We'll have to evaluate the amount of churn this generates, but overall it would makes sense to keep related things together, and apply the markers sensibly. [...] > > > +#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? They emit instructions if you make use of them. And so do all the PSTATE macros. Why the different treatment? Thanks, M. -- Jazz isn't dead. It just smells funny.