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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 76446C7115B for ; Mon, 23 Jun 2025 09:20:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RpEBy0jOsHwPp2AMdHOGAyhQpQmhIZuo0GX5sSx4urU=; b=b9Y1cnQyN5o+oZ8NRLP4An0CP+ DCAcbuEmgiT6s8t4afOW4MlmFvZj1XX6WXLiQdwIdeqO5HPDrTHEknzW7q3DhdGHZRfO+qgT2R6BB ncfgEbYFJjXPuBuMjKuyFpCoP1YkNtMpHDHFPArUhCxvoQ3ZYpAch++6EHXbXq2JzqitIEx6vgJ7E /JisgPrGWF00R5pUbgtuxwv+4tY2s6M4RRoqLxL8spJpDiKLTimhpHOjp/HpdD3KezC6FKXyQjtNb zWYEKDSzG7GSn8tmc5/R0SNbfL5xQt9q3rrvl9xbrNeSj7mJR1bf2WH2iMYAh4IPlSguSGGIFrWqm I9qteLEw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uTdLv-000000029QQ-02Tg; Mon, 23 Jun 2025 09:20:35 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uTd7a-000000026dT-3HmC for linux-arm-kernel@lists.infradead.org; Mon, 23 Jun 2025 09:05:48 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id AE82D5C58FA; Mon, 23 Jun 2025 09:03:29 +0000 (UTC) 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) 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250623_020546_906207_D5FDAD91 X-CRM114-Status: GOOD ( 25.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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.