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 lists1p.gnu.org (lists1p.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 CA316CD8C9D for ; Mon, 8 Jun 2026 14:08:51 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wWaeW-0000lE-D3; Mon, 08 Jun 2026 10:08:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wWaeT-0000kw-RG for qemu-arm@nongnu.org; Mon, 08 Jun 2026 10:08:29 -0400 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wWaeS-0001HB-7h for qemu-arm@nongnu.org; Mon, 08 Jun 2026 10:08:29 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id B94F76001D; Mon, 8 Jun 2026 14:08:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DD281F00893; Mon, 8 Jun 2026 14:08:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780927706; bh=uQbeUTHlxW33ePNUtyeXO5I2zGh86vHk5u66ukHFhAw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Rq9vaEM4+NIV3eOXVxxEjTDZA/rqgkZVgfe6Sz+3TgYabalz6Kq/VoQXvzN5Ym8mA 3sioXkkXS29eX8QEpjNt+H8K0T1fX9plm2tmzTDholVloS9/4c0Xfsv8w+1MsM6bGi rh1LVbEWmc6uFvWePU4vjw3i0A8ZFFH3+coBJ7SzlsYWQCt1OAmHCE2NQCpKtvyLwN rIAmG1NB/PxtXFUgGw7M2V1cdfQIIgHN+ir1HczEHe8TZNw0PwlfyzARVG9t5N9sT/ ujQPnYIBnIDQQS52FxGM5oQQhFvZfpr2S2JVIsBjl0Q5/w0K39XZMEzO1yXtmVJ0uP wgLlFlmT+NazQ== 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.98.2) (envelope-from ) id 1wWaeN-0000000AVTv-46jL; Mon, 08 Jun 2026 14:08:24 +0000 Date: Mon, 08 Jun 2026 15:08:23 +0100 Message-ID: <86pl21t99k.wl-maz@kernel.org> From: Marc Zyngier To: Khushit Shah Cc: "kvmarm@lists.linux.dev" , "oupton@kernel.org" , "eric.auger@redhat.com" , "cohuck@redhat.com" , "peter.maydell@linaro.org" , "qemu-arm@nongnu.org" , Mark Cave-Ayland , Shaju Abraham Subject: Re: [RFC] Exposing arm64 ID-register safe_rules semantics to userspace? In-Reply-To: References: <86se6xthih.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/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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: khushit.shah@nutanix.com, kvmarm@lists.linux.dev, oupton@kernel.org, eric.auger@redhat.com, cohuck@redhat.com, peter.maydell@linaro.org, qemu-arm@nongnu.org, mark.caveayland@nutanix.com, shaju.abraham@nutanix.com 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=2600:3c04:e001:324:0:1991:8:25; envelope-from=maz@kernel.org; helo=tor.source.kernel.org X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.445, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-arm@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-arm-bounces+qemu-arm=archiver.kernel.org@nongnu.org Sender: qemu-arm-bounces+qemu-arm=archiver.kernel.org@nongnu.org On Mon, 08 Jun 2026 14:28:13 +0100, Khushit Shah wrote: > > On 8 Jun 2026, at 4:40=E2=80=AFPM, Marc Zyngier wrote: > >=20 > > My question above still stands: why isn't knowing that a field is > > writable or not, together with the max value of that field, enough to > > decide what is possible to be set for that field? >=20 > Okay, makes sense, there are 57 fields in cpufeatures.c that are not > unsigned FTR_LOWER_SAFE.=20 >=20 > Right now, only 21 of those are writable. 8 of those are single bit, > with FTR_EXACT and safe_value as 0, so no special case for them. >=20 > So, only special handling for 13 fields are needed for now: >=20 > EXACT: 4 (TGRAN*_2, L1Ip) > SIGNED_LOWER_SAFE: 7 (TGRAN4, TGRAN64, InnerShr, OuterShr, DoubleLock, PM= UVer, PerfMon) > HIGHER_SAFE: 2 (SpecSEI) >=20 > Hardcoding these 13 works for today=E2=80=99s kernel. But when new fields= are made > writable or are added to ftr_bits, older VMM will by default make assumpt= ion > of them as LOWER_SAFE, which might be wrong. Hardcoding *anything* feels very wrong. Each of these features is handled differently for a number of reasons that are related to the architecture itself and the way the kernel is using it *for itself*. This information is not supposed to be consumed by userspace, and is not exposed to it. The problem you seem to have here is that you want to deal with these features without capturing any understanding of what these actually mean in the context of the architecture. I can't see a good outcome of that sort of thing in the long run. The VMM is, for better or worse, part of the overall hypervisor. It cannot treat the features as a bag of bits. This is also why the whole "CPU model" thing is IMO a bad idea: it is syntactic sugar that falls at the first hurdle, simply because the architecture is not fully virtualisable. For example you can't take a Neoverse V2 description and apply it to a KVM guest running on V2 HW. I think you need to revisit your approach to this stuff. M. --=20 Without deviation from the norm, progress is not possible.