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 21E4FC4321E for ; Sun, 4 Dec 2022 18:53:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zD1BbXsYPWz4COwP8MO2miPgxryCFbNAFsKVJNZLOFc=; b=bnIcn9kWE8i5Xa p5bl0370gFR2fq2xgxQWft6Yi2o+N2cT7uUKd2miPbUFWuhxZDKVTt8jfVkbOunipNtZWymCHCawG g5XolQGiVbb6wUCzlOOy8H39o4r1AIg2bTqm2tlDqpjn/j+EiQTsIoa2pPzClaE7VXoj2S6ybfMwY YkPRac+6PsvY8ABxT3DnD8tjzuOFKQZnCtOfzxcT4VNGMN6scvwcxqZKsms52Mg2M4nAbGvkoekRG 50v+oZHNJbExmuL5MTe8dC5cYXRoLgcoty4/lepDGMHXU/2Eq04EnyOh1xklI7/3K0rwqL9iCFHV+ VtP4mz2cSv5z4Kx5taXw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p1u6M-00APdf-3g; Sun, 04 Dec 2022 18:52:34 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p1qRL-008uxr-Pl for linux-arm-kernel@lists.infradead.org; Sun, 04 Dec 2022 14:58:01 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2DB6360EA0; Sun, 4 Dec 2022 14:57:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7EAC0C433C1; Sun, 4 Dec 2022 14:57:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670165877; bh=Cgm74NkKEZ/DK5RPHt06OPQZsab/+7Dm33HMyFy16EQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IBbWkhGldTnPxTm2GnBQewKJxktXrW8xPU5icmaUJHIc6PcgSX9oSrvnxV9D8cLcl jPYkNrjmWwB3TIlWFYT28Jv8O5lZHK/R3WTQP7i+bwz+oasHthcsKkk2XFtg+IVVZa Xc1hn1YayMhURTJIVCoswxTnOiAJv2JLbOegzL1Dix3VwQXPka+7IUorL1/j11AV0W W0VXR3DgPel2+vk7UyFeUKTOq9+TnNDLS8nmmDXYz0+Rztow0DSCl9KLFTWNPT8H0F FOE8A8wVMGTr68t9Hi23GWKt1E7EcQMEjzKRI0ZkwI3LRCfezpbpTS/zIx0DGQtycg u0GvX8eDS/veQ== Received: from [82.141.251.28] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1p1qRG-00AP6F-Pg; Sun, 04 Dec 2022 14:57:54 +0000 Date: Sun, 04 Dec 2022 14:57:53 +0000 Message-ID: <87bkojtdvy.wl-maz@kernel.org> From: Marc Zyngier To: Akihiko Odaki Cc: Akihiko Odaki , linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Mathieu Poirier , Oliver Upton , Suzuki K Poulose , Alexandru Elisei , James Morse , Will Deacon , Catalin Marinas , asahi@lists.linux.dev, Alyssa Rosenzweig , Sven Peter , Hector Martin Subject: Re: [PATCH 0/3] KVM: arm64: Handle CCSIDR associativity mismatches In-Reply-To: References: <20221201104914.28944-1-akihiko.odaki@daynix.com> <867czbmlh1.wl-maz@kernel.org> <50499ee9-33fe-4f5d-9d0a-76ceef038333@daynix.com> <87lenqu37t.wl-maz@kernel.org> <525ff263-90b3-5b12-da31-171b09f9ad1b@daynix.com> <87h6yeta8b.wl-maz@kernel.org> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 82.141.251.28 X-SA-Exim-Rcpt-To: akihiko.odaki@gmail.com, akihiko.odaki@daynix.com, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, mathieu.poirier@linaro.org, oliver.upton@linux.dev, suzuki.poulose@arm.com, alexandru.elisei@arm.com, james.morse@arm.com, will@kernel.org, catalin.marinas@arm.com, asahi@lists.linux.dev, alyssa@rosenzweig.io, sven@svenpeter.dev, marcan@marcan.st X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221204_065759_990988_CB4272D3 X-CRM114-Status: GOOD ( 36.39 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 02 Dec 2022 09:55:24 +0000, Akihiko Odaki wrote: > > On 2022/12/02 18:40, Marc Zyngier wrote: > > On Fri, 02 Dec 2022 05:17:12 +0000, > > Akihiko Odaki wrote: > >> > >>>> On M2 MacBook Air, I have seen no other difference in standard ID > >>>> registers and CCSIDRs are exceptions. Perhaps Apple designed this way > >>>> so that macOS's Hypervisor can freely migrate vCPU, but I can't assure > >>>> that without more analysis. This is still enough to migrate vCPU > >>>> running Linux at least. > >>> > >>> I guess that MacOS hides more of the underlying HW than KVM does. And > >>> KVM definitely doesn't hide the MIDR_EL1 registers, which *are* > >>> different between the two clusters. > >> > >> It seems KVM stores a MIDR value of a CPU and reuse it as "invariant" > >> value for ioctls while it exposes the MIDR value each physical CPU > >> owns to vCPU. > > > > This only affects the VMM though, and not the guest which sees the > > MIDR of the CPU it runs on. The problem is that at short of pinning > > the vcpus, you don't know where they will run. So any value is fair > > game. > > Yes, my concern is that VMM can be confused if it sees something > different from what the guest on the vCPU sees. Well, this has been part of the ABI for about 10 years, since Rusty introduced this notion of invariant, so userspace is already working around it if that's an actual issue. This would be easily addressed though, and shouldn't result in any issue. The following should do the trick (only lightly tested on an M1). Thanks, M. >From f1caacb89eb8ae40dc38669160a2f081f87f4b15 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Sun, 4 Dec 2022 14:22:22 +0000 Subject: [PATCH] KVM: arm64: Return MIDR_EL1 to userspace as seen on the vcpu thread When booting, KVM sample the MIDR of the CPU it initialises on, and keep this as the value that will forever be exposed to userspace. However, this has nothing to do with the value that the guest will see. On an asymetric system, this can result in userspace observing weird things, specially if it has pinned the vcpus on a *different* set of CPUs. Instead, return the MIDR value for the vpcu we're currently on and that the vcpu will observe if it has been pinned onto that CPU. For symmetric systems, this changes nothing. For asymmetric machines, they will observe the correct MIDR value at the point of the call. Reported-by: Akihiko Odaki Signed-off-by: Marc Zyngier --- arch/arm64/kvm/sys_regs.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index f4a7c5abcbca..f6bcf8ba9b2e 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1246,6 +1246,22 @@ static int set_id_reg(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd, return 0; } +static int get_midr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd, + u64 *val) +{ + *val = read_sysreg(midr_el1); + return 0; +} + +static int set_midr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd, + u64 val) +{ + if (val != read_sysreg(midr_el1)) + return -EINVAL; + + return 0; +} + static int get_raz_reg(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd, u64 *val) { @@ -1432,6 +1448,7 @@ static const struct sys_reg_desc sys_reg_descs[] = { { SYS_DESC(SYS_DBGVCR32_EL2), NULL, reset_val, DBGVCR32_EL2, 0 }, + { SYS_DESC(SYS_MIDR_EL1), .get_user = get_midr, .set_user = set_midr }, { SYS_DESC(SYS_MPIDR_EL1), NULL, reset_mpidr, MPIDR_EL1 }, /* @@ -2609,7 +2626,6 @@ id_to_sys_reg_desc(struct kvm_vcpu *vcpu, u64 id, ((struct sys_reg_desc *)r)->val = read_sysreg(reg); \ } -FUNCTION_INVARIANT(midr_el1) FUNCTION_INVARIANT(revidr_el1) FUNCTION_INVARIANT(clidr_el1) FUNCTION_INVARIANT(aidr_el1) @@ -2621,7 +2637,6 @@ static void get_ctr_el0(struct kvm_vcpu *v, const struct sys_reg_desc *r) /* ->val is filled in by kvm_sys_reg_table_init() */ static struct sys_reg_desc invariant_sys_regs[] = { - { SYS_DESC(SYS_MIDR_EL1), NULL, get_midr_el1 }, { SYS_DESC(SYS_REVIDR_EL1), NULL, get_revidr_el1 }, { SYS_DESC(SYS_CLIDR_EL1), NULL, get_clidr_el1 }, { SYS_DESC(SYS_AIDR_EL1), NULL, get_aidr_el1 }, -- 2.34.1 -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel