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 E61AE3C9EFB for ; Mon, 8 Jun 2026 14:08:26 +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=1780927710; cv=none; b=psPvezCrilCpuj7mHLinLrhiBGTUbVl3VdCjuHsR3ZJj0kxdDChwp3KZ1wVwiGk424Q2+H0Qe/rH7t61w9PBq2ohJGn++5QdXr3jTk+AxXOxRXIDwsQ1vhXjxyXPb8IupwsbZTQbE5K2RYibFP01JJI+wfljXkmUAMmPcrqzBQk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780927710; c=relaxed/simple; bh=rW7Uo1G+PXsx+UnaleG4DkWcKETJEmDCkf3BP7R1oFc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=dsLZEHS0ADI7S/R1UnRrmpIdt6Jv2Xi5umU9WihKH6S5qn8CkBdlpqW0u5gRCepgVd3jPXYRCIxh6GvXEuDL+DOpQNLLYT3CbilMVI5+gNueF6pA2DSSyC9Awd/iYtvmz4f6G6jvRpigoBPyJl9un8NQQiV7PA09L5yWzoHofMQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Rq9vaEM4; 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="Rq9vaEM4" 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) 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=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 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.