From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5A80942DA2E; Mon, 13 Jul 2026 15:40:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783957220; cv=none; b=ctQJPIk1dB3qmeevGqN3eqC1cXOsaHmoOW4GwC7e2cwulDFioyFZeY8oiV4HuHZaU7Ze7ejkzLDjh4G0xnypucn0XcqiQE+UVUH4gn+qpBGTsX+fJA+FGwLYqRnB4ZPoTXPV0JM6ugswdzOYIYqoEPCA3/t1cGrnWWld/415yWY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783957220; c=relaxed/simple; bh=1RP7nIJvZuzFUVz7LbE/87Gze67ycwP4Zd0J1lCM4X4=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=GUYNWELN8z64OiKkvCYeDHP6NheYmCJD4lLkLcqW1CCVv2U2Zds3pEqdHsLsLu0ynbwtrOvx8PGdbXpKFiEveMIIqY6D2qTyH42rRrtCFPmbqMJVuzzgfcGOe2rq7fThl6+PCm1oUrVz50Q45WJLXwB5Q/YetgmpM7N7CjDG4Ww= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Cn2ZUCB+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Cn2ZUCB+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F25771F000E9; Mon, 13 Jul 2026 15:40:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783957219; bh=bgGgHEFrLGkQhpGDdK+yppM68Mi1G34yHD+nEZ0cRvI=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Cn2ZUCB+DP+A+yh8GoVyIuambcgu9zH+5DmmoJPwToYOYq2t2XeVgJO9coDBBFNjk 81ZA7FFzrTucxbUJF7pwryMqEmNaBcfaKPuwAIwEZoiOZ5e4FB2MRdTTJqMSNoXIUj s5k7KVSP+1VHiZB1j1ulfEzWbLKtlwJqy1Ch0aJkHXnxnhEP0ML/V244TtoHApg79A 69yy93M65/CibCsFPLu/xMTTe9vPbz2E7n7fnDAU4MfIH1rXSHSuagQgyXn7RXB3c6 ySWxQhLOHBX6QHlFiWUnSnDEe+SPVCcpI58lu2N6i2KrU6+0PY5PAJuUF++T+tcdHm FrGMRexNuXUog== 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 1wjIlV-00000004YRs-09Of; Mon, 13 Jul 2026 15:40:17 +0000 Date: Mon, 13 Jul 2026 16:42:06 +0100 Message-ID: <87a4ru6gmp.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 09/27] KVM: arm64: Access elements of vcpu_gp_regs individually In-Reply-To: <20260710115637.984749-H-seiden@linux.ibm.com> References: <20260706085229.979525-1-seiden@linux.ibm.com> <20260706085229.979525-10-seiden@linux.ibm.com> <86cxx0ovx5.wl-maz@kernel.org> <20260710115637.984749-H-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) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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 On Fri, 10 Jul 2026 12:56:37 +0100, Steffen Eiden wrote: > > On Mon, Jul 06, 2026 at 06:44:06PM +0100, Marc Zyngier wrote: > > On Mon, 06 Jul 2026 09:52:09 +0100, > > Steffen Eiden wrote: > > > > > > While for arm64 the members of vcpu_gp_regs are allocated continuous > > > this is not necessarily true for other architectures implementing ARM. > > > > > > Let vcpu_gp_regs() no longer return the address of the user_pt_regs in > > > the vcpu context but the address of the gp-register array field in the > > > user_pt_reg struct. > > > > That's an interesting change of semantics, because this excludes PC > > from the GPRs. This is valid on AArch64, but wrong for AArch32 (PC > > really is R15, and is just another GPR). > > > > I never looked into AArch32 thanks for pointing this out. > > > It isn't a huge deal, and nothing breaks, but that's something that > > you may want to capture. > > > > Shall I add a comment into the commit message that this splits pc from > the gprs for arm32? Yeah, I really want this stuff to be correctly documented, just in case we break something and have to go back in time to find out why. That's overall something that could be improved in this series. [...] > > > diff --git a/arch/arm64/kvm/hyp/exception.c b/arch/arm64/kvm/hyp/exception.c > > > index bef40ddb16db..82611442a2d1 100644 > > > --- a/arch/arm64/kvm/hyp/exception.c > > > +++ b/arch/arm64/kvm/hyp/exception.c > > > @@ -277,6 +277,9 @@ static const u8 return_offsets[8][2] = { > > > [7] = { 4, 4 }, /* FIQ, unused */ > > > }; > > > > > > +#define OFFSETOF_PT_REG(__r) offsetof(struct user_pt_regs, __r) > > > +#define COMPAT_IDX(__c) ((OFFSETOF_PT_REG(__c) - OFFSETOF_PT_REG(regs[0])) / sizeof(u64)) > > > + > > > > Oh $gawd, this is... awful. > > > > > static void enter_exception32(struct kvm_vcpu *vcpu, u32 mode, u32 vect_offset) > > > { > > > unsigned long spsr = *vcpu_cpsr(vcpu); > > > @@ -292,12 +295,12 @@ static void enter_exception32(struct kvm_vcpu *vcpu, u32 mode, u32 vect_offset) > > > switch(mode) { > > > case PSR_AA32_MODE_ABT: > > > __vcpu_write_spsr_abt(vcpu, host_spsr_to_spsr32(spsr)); > > > - vcpu_gp_regs(vcpu)->compat_lr_abt = return_address; > > > + vcpu_gp_regs(vcpu)[COMPAT_IDX(compat_lr_abt)] = return_address; > > > break; > > > > Stupid idea: why don't you simply have new #defines that make the > > register number standalone, and make ptrace.h use that? Something line > > this (which can obviously be extended to all the compat registers): > > > > diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h > > index 39582511ad72f..2d3d324d2598e 100644 > > --- a/arch/arm64/include/asm/ptrace.h > > +++ b/arch/arm64/include/asm/ptrace.h > > @@ -104,6 +104,10 @@ > > #define COMPAT_USER_SZ 296 > > > > /* Architecturally defined mapping between AArch32 and AArch64 registers */ > > +enum aarch32_reg_mapping { > > + __compat_lr_und = 22, > > +}; > > + > > #define compat_usr(x) regs[(x)] > > #define compat_fp regs[11] > > #define compat_sp regs[13] > > @@ -115,7 +119,7 @@ > > #define compat_sp_svc regs[19] > > #define compat_lr_abt regs[20] > > #define compat_sp_abt regs[21] > > -#define compat_lr_und regs[22] > > +#define compat_lr_und regs[__compat_lr_und] > > #define compat_sp_und regs[23] > > #define compat_r8_fiq regs[24] > > #define compat_r9_fiq regs[25] > > > > and then your #defines from hell can go? > > Great suggestion I do not like this macro hell myself. I'll implement it > that way. Should I convert all compat_* regs to this concept or just the > ones I need? All of them, please., I value consistency. As you are doing this, consider adding a reference to I_PYKVS, which describes the mapping in the ARM ARM. Thanks, M. -- Jazz isn't dead. It just smells funny.