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 9363434107D for ; Mon, 8 Jun 2026 11:10:16 +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=1780917017; cv=none; b=gstEhxZJ1a3q88aSt0hRldkD1ZvXqTbZnsIiOLft3ITN+4kwsAEsd+gxBFWreAmdf4uRV/nxBurHzaJ8L6Q03LXv0e75K22WoX2OhOqNKgk5Ziro2T1YN9bJ6nYqDT/LZb/GijnZ0Ht8u0cjpYMQQWetiQ/h7DDPc6wOMC51yvI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780917017; c=relaxed/simple; bh=Ws0y5BGKgtOoiq8J5RM73L6W45x0TRUDlGle5Q5dMO4=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=g+ZNTrGvCffi8ZnAVbOK7+lnw1yx4/Jkd5wPNLcsMetA2NnKT5WgFx5nO07ZzxyoEfkKNSDXcazxVX3LIYrUx1IXifPH8v5IaztA+e+0j82jHbzdgpg5IstUtQdFbls7GeuT8tzVYqYY6aQqMDy/cX8fXyy2u8HkADq+QrabPBY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fwbgGu2q; 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="fwbgGu2q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F7351F00893; Mon, 8 Jun 2026 11:10:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780917016; bh=V7zfnW6nG1q4H+6d51ekdTAwkP6IvVfSqyDMcp3bDKw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=fwbgGu2qUhVSeI+9xzPhv91D0+6uOqK0xMD8xvQUqaVkchFhLkQ3q9jbmN8Tx5jrs V148OFWCeJRCLcGJoKOrDhNlIfKd65W6GAYzIErBnrzwRlf4qWgweHNGskz//k8yA6 yGO9wb7bd3fUwLKxDENkkxeMtUobely6fzYlxetv5AwOJqfuuK1PAhwXGzLH3APF7g jr6dmv9nCn0LzSISTfiZ/LQqjNUJzZlCq8fYb6ng7aZEx9P5VOWJvbP+PP3nlPwt3D M3ig3vMRja3TT7H+Pb6NGmtBaFsPH6yE7g6SkqfEv71a9sSqj45fSplX/pDIZ68aVm F74qrrChkrrag== 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 1wWXry-0000000ARdp-1lQ9; Mon, 08 Jun 2026 11:10:14 +0000 Date: Mon, 08 Jun 2026 12:10:14 +0100 Message-ID: <86se6xthih.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: 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: 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 10:43:11 +0100, Khushit Shah wrote: > > Hi all, > > On KVM_SET_ONE_REG for ID registers, KVM validates the requested > field values against the host's values using the per-field rules > in arm64_ftr_bits[](arch/arm64/kernel/cpufeature.c) (and, some > KVM specific overrides on top); > > In our QEMU RFC for named ARM CPU models [1], we use the safe_rules to: > - pre-validate a guest ID register configuration before KVM write back, Pre-validate *how*? > - report blockers in QMP query-cpu-definitions for a given named > model, Sorry, but I have no idea what this is. > - enumerate supported values per field for QMP/libvirt/upper layers. > > RFC has a hand-maintained copy of safe_rules in QEMU that mirrors > the kernel. > > Any advice for VMMs on how to track the safe_rules used by KVM to > validate ID-register field values written by userspace? Why should the VMM care? Either a field is exposed as writable, and in general it is safe to expose something "lower" than the host value to the guest, or it isn't, and only that particular value is possible. There is a few exceptions to this rule, but I expect this to be the minority. > > There is no API that exposes those rules to VMMs. Until a VMM issues > KVM_SET_ONE_REG, it cannot know whether the requested set of values > will be accepted. On failure, VMM still cannot know the faulting field. > > We'd like to know what the right approach is: > - Should there be a KVM ioctl that exposes the safe_rules to > userspace? > Maybe Something like KVM_GET_SAFE_RULE (that takes reg_idx and > start_bit_pos) > or a bulk ioctl like KVM_GET_REG_SAFE_RULES (that returns (reg_idx, > start_bit, width, safe_rule, safe_vals) for all the ID registers? > - Is it acceptable to keep mirroring ftr_bits[] in userspace? > - Or is this simply not meant to be exposed to userspace VMMs? 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? Thanks, M. -- Without deviation from the norm, progress is not possible.