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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 85EE3CA0EDC for ; Thu, 14 Aug 2025 08:11:51 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1umT3W-00033E-Jp; Thu, 14 Aug 2025 04:11:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1umT3R-00032V-H5 for qemu-devel@nongnu.org; Thu, 14 Aug 2025 04:11:22 -0400 Received: from tor.source.kernel.org ([172.105.4.254]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1umT3N-0001aq-3A for qemu-devel@nongnu.org; Thu, 14 Aug 2025 04:11:20 -0400 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 6266660209; Thu, 14 Aug 2025 08:11:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 180E0C4CEEF; Thu, 14 Aug 2025 08:11:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1755159068; bh=zPcej9q0M1ji9SBAbwmwb0bKVjgCbJuyYpRyZwuMqKk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mSQi4tXImKf0v+f/jvSQa66DgrrTk6bi/b2xMIlRLi/rXN7XvxoF5PjsEVc1bMHz+ nI+4w5u8uVzp7+3nUYTfw/0RvmAq4FucIho2AUWg2hAzzvn/q+uk0PsGKga/Sx4h5c d7ZNZT/84l+m8RGepB44q2Op2blrlOGoxlDWuoZGvLPNJT/C5ZFGc3NlZXWylhdLvr TPmI63/Dy9UntyaoL5a3Ph3G90VNC3AVvdYR/AALwNM8X9YfjPc0HXpQmJ+MpJQd+n vjSnESr5HxhSBNK1xeLCxM/EXvkBCYjVHsmHMXAFFJ/7sGOZc9YAEFjdmS3cFXeKA6 IEL1LnqbBuoZw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1umT37-007Lun-0f; Thu, 14 Aug 2025 09:11:01 +0100 Date: Thu, 14 Aug 2025 09:11:00 +0100 Message-ID: <86cy8y8grv.wl-maz@kernel.org> From: Marc Zyngier To: Richard Henderson Cc: kvmarm@lists.linux.dev, qemu-devel , Peter Maydell , Oliver Upton , Alex =?UTF-8?B?QmVubsOpZQ==?= Subject: Re: KVM sysreg ids for FEAT_SYSREG128 In-Reply-To: <1c6b4f19-6cb2-4da0-9acc-d63307880de1@linaro.org> References: <1c6b4f19-6cb2-4da0-9acc-d63307880de1@linaro.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/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: richard.henderson@linaro.org, kvmarm@lists.linux.dev, qemu-devel@nongnu.org, peter.maydell@linaro.org, oliver.upton@linux.dev, alex.bennee@linaro.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Received-SPF: pass client-ip=172.105.4.254; envelope-from=maz@kernel.org; helo=tor.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Hi Richard, Thanks for bringing this up. FEAT_D128 is not on anyone's radar on the KVM side (I really don't fancy having to write another set of page table walkers), but it doesn't hurt to be prepared. On Thu, 14 Aug 2025 00:27:25 +0100, Richard Henderson wrote: > > Hiya, > > QEMU (ab)uses the kvm encoding of system register ids in the migration > stream. As we implement support for FEAT_D128, it would be good to > agree on an encoding for the 128-bit registers so that we can avoid > complications with migration later. > > I don't think this is terribly complicated. Simply adjust the value > in the KVM_REG_SIZE_MASK field from U64 to U128. E.g. > > PAR_EL1 (64-bit) (__ARM64_SYS_REG(3, 0, 7, 4, 0) | KVM_REG_SIZE_U64) > PAR_EL1 (128-bit) (__ARM64_SYS_REG(3, 0, 7, 4, 0) | KVM_REG_SIZE_U128) > > This will currently be cleanly rejected by index_to_params, resulting > in ENOENT for the ioctl. When KVM grows support for D128 guests, > kvm_sys_reg_{get,set}_user can select the read/write code path based > on reg->id & KVM_REG_SIZE_MASK. > > Comments? The encoding of the register, as described above, is absolutely fine. But since you brought the subject, I'd like to align on a bit more than the encoding. The way I see imagine it after two cups of coffee (which clearly isn't enough) is to have a feature bit provided at VM creation time, enabling D128 support, HW support allowing. At that point, querying the list of supported sysregs would report the 128bit versions of TTBR{0,1}_EL{1,2}, VTTBR_EL2, and PAR_EL1 (ignoring things we are unlikely to ever support, such as FEAT_THE). The 64bit versions of these registers would not be reported. Does that align with what QEMU would do internally? Thanks, M. -- Without deviation from the norm, progress is not possible.