From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 0E7F922F74E; Mon, 23 Jun 2025 09:05:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750669546; cv=none; b=bhwUnu2HKOnIDjrN8rz1WI115tFMC5c21iglcR3Knnh1P0FcOePJW0oYa+9dPNM6pNrI3oZoNDfni4ZMNaGnc1MfOnRTpGFKoM/aKnjWyd2mVDOIxlFjmyJFKGkaXorhc+q0nyFUedw1OK6v3dQeubbG5fn7deEaRdXE07NOjrg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750669546; c=relaxed/simple; bh=UQtpKkCNK/ydA/BGLNBKX3hmfJ58T1rD0l8E43Ckjyw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=f+JbKB7kOqhWkX5HbumBMd6+YAYk1+dcEL1kBFx7hYu+1JCOK/5OAU1vYx8I1yFE+Mtk0qnMqaJvFeot5QPTlq25GgR4Pyl3JdgCOWP235915GhOPX8RqiAW20oR1UZkhep+0p+AxhBG5zkvUzzeVKkMS42RIa9k4IAZzmbPbRs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RdwNAsk/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RdwNAsk/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D786BC4CEEA; Mon, 23 Jun 2025 09:05:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750669545; bh=UQtpKkCNK/ydA/BGLNBKX3hmfJ58T1rD0l8E43Ckjyw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RdwNAsk/8b7WLbAxEMp1SS3DyQKQ4MKz8D03+cE6S+ArTXiVisYG9wF410ACpoqq2 MQjJwmiG0UCQ9jSboMnpuA3UlOnCywiOifZjOSNHRTgkvf03uUhA72Veum88iRVuCc pNoYneMfGqzCKBbLfvIERKnD3u9We8NU2Hsc5Qeob0BpKl5CP3Fb+csjI7qoTqLJrX SEpQAmhfLNvjZq/Kxp2DXUduqy0iEmUBWJgmA2rJVx3iXl6keckrbZK9DLhkt/8Tkm A3bRxUsGauu5MdlqZR9oAfJ6PBMqi45NuQxLLlAwlTf+OdwI4h4zi8yJjOVSuo7LYj Iye6m91OBcEjw== 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 1uTd7X-0097hz-BJ; Mon, 23 Jun 2025 10:05:43 +0100 Date: Mon, 23 Jun 2025 10:05:42 +0100 Message-ID: <868qliddzt.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Raghavendra Rao Ananta , Mingwei Zhang , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v3 3/4] KVM: arm64: Introduce attribute to control GICD_TYPER2.nASSGIcap In-Reply-To: References: <20250613155239.2029059-1-rananta@google.com> <20250613155239.2029059-4-rananta@google.com> <87frftfpg7.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: kvm@vger.kernel.org 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: oliver.upton@linux.dev, rananta@google.com, mizhang@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 23 Jun 2025 09:40:46 +0100, Oliver Upton wrote: > > On Sat, Jun 21, 2025 at 09:50:48AM +0100, Marc Zyngier wrote: > > On Fri, 13 Jun 2025 16:52:37 +0100, Raghavendra Rao Ananta wrote: > > > @@ -683,8 +714,14 @@ static int vgic_v3_has_attr(struct kvm_device *dev, > > > return 0; > > > case KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES: > > > return 0; > > > + default: > > > + return -ENXIO; > > > } > > > + case KVM_DEV_ARM_VGIC_GRP_FEATURES: > > > + return attr->attr != KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap ? > > > + -ENXIO : 0; > > > > Do we really want to advertise KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap even > > when we don't have GICv4.1? This seems rather odd. My take on this API > > is that this should report whether the feature is configurable, making > > it backward compatible with older versions of KVM. > > So this was because of me, as I wanted nASSGIcap to behave exactly like > the ID registers. I do think exposing the capability unconditionally is > useful, as otherwise there's no way to definitively say whether or not > the underlying platform supports GICv4.1. > > KVM_HAS_DEVICE_ATTR can't be used alone for probing since old kernels > use GICv4.1 but don't expose the attribute. > > Does that make sense? My own reasoning is that if we expose the capability, userspace is able to use it and rely on it to take effect (VPE allocation error notwithstanding). This is not the case with this approach, and that's at odds with the other attributes. But taking a step back: if we want to control the nASSGIcap bit, why don't we allow writing to GICD_TYPER2 from userspace? This does matches your view that we treat it as an ID register (GICD_TYPER2 matches this definition if you squint hard enough). It also avoids adding new UAPI with unusual semantics. Has this been considered? Thanks, M. -- Without deviation from the norm, progress is not possible.