From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 F2562A94A for ; Mon, 14 Aug 2023 09:46:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692006405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=K4sGVUE43D+9dWlB8T8cOXLzUkJGkxQXnJLqjpcMDso=; b=gzLH5q0j2MrmTDqiouzzuNYVddpPdDEPmp0A/PuQHscGRmC6EyOKrdXCczUBWLP1Dlmb9e aT4PoIFKQ1SOl0tX0VBzX45CNyoknEM5w6N24ot5DLR5Rxc6tuqY4QSZ0Yzp4zpby8fmMS 8Y7BuaPlxU1RFbRfZuPXEMOeQ0K0sgY= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-59-V1JhcZPKNna7_WvWh_0YbA-1; Mon, 14 Aug 2023 05:46:42 -0400 X-MC-Unique: V1JhcZPKNna7_WvWh_0YbA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 299DD3815F62; Mon, 14 Aug 2023 09:46:41 +0000 (UTC) Received: from localhost (dhcp-192-239.str.redhat.com [10.33.192.239]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DC2D12166B25; Mon, 14 Aug 2023 09:46:40 +0000 (UTC) From: Cornelia Huck To: Jing Zhang , KVM , KVMARM , ARMLinux , Marc Zyngier , Oliver Upton Cc: Will Deacon , Paolo Bonzini , James Morse , Alexandru Elisei , Suzuki K Poulose , Fuad Tabba , Reiji Watanabe , Raghavendra Rao Ananta , Suraj Jitindar Singh , Jing Zhang Subject: Re: [PATCH v8 02/11] KVM: arm64: Document KVM_ARM_GET_REG_WRITABLE_MASKS In-Reply-To: <20230807162210.2528230-3-jingzhangos@google.com> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross" References: <20230807162210.2528230-1-jingzhangos@google.com> <20230807162210.2528230-3-jingzhangos@google.com> User-Agent: Notmuch/0.37 (https://notmuchmail.org) Date: Mon, 14 Aug 2023 11:46:39 +0200 Message-ID: <878raex8g0.fsf@redhat.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 On Mon, Aug 07 2023, Jing Zhang wrote: > Add some basic documentation on how to get feature ID register writable > masks from userspace. > > Signed-off-by: Jing Zhang > --- > Documentation/virt/kvm/api.rst | 29 +++++++++++++++++++++++++++++ > 1 file changed, 29 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index c0ddd3035462..92a9b20f970e 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -6068,6 +6068,35 @@ writes to the CNTVCT_EL0 and CNTPCT_EL0 registers using the SET_ONE_REG > interface. No error will be returned, but the resulting offset will not be > applied. > > +4.139 KVM_ARM_GET_REG_WRITABLE_MASKS > +------------------------------------------- > + > +:Capability: none > +:Architectures: arm64 > +:Type: vm ioctl > +:Parameters: struct reg_mask_range (in/out) > +:Returns: 0 on success, < 0 on error > + > + > +:: > + > + #define ARM64_FEATURE_ID_SPACE_SIZE (3 * 8 * 8) > + > + struct reg_mask_range { > + __u64 addr; /* Pointer to mask array */ > + __u64 reserved[7]; > + }; > + > +This ioctl would copy the writable masks for feature ID registers to userspace. > +The Feature ID space is defined as the System register space in AArch64 with > +op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7}, op2=={0-7}. > +To get the index in the mask array pointed by ``addr`` for a specified feature > +ID register, use the macro ``ARM64_FEATURE_ID_SPACE_IDX(op0, op1, crn, crm, op2)``. > +This allows the userspace to know upfront whether it can actually tweak the > +contents of a feature ID register or not. > +The ``reserved[7]`` is reserved for future use to add other register space. For > +feature ID registers, it should be 0, otherwise, KVM may return error. In case of future extensions, this means that userspace needs to figure out what the kernel supports via different content in reg_mask_range (i.e. try with a value in one of the currently reserved fields and fall back to using addr only if that doesn't work.) Can we do better? Maybe we could introduce a capability that returns the supported ranges as flags, i.e. now we would return 1 for id regs masks, and for the future case where we have some values in the next reserved field we could return 1 & 2 etc. Would make life easier for userspace that needs to work with different kernels, but might be overkill if reserved[] is more like an insurance without any concrete plans for extensions. 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 8E417EB64DD for ; Mon, 14 Aug 2023 09:47:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kIXZ/2uc+quYQbQrBox2xgSK+V6oU9xw7YOep6uuJR4=; b=HdK9ErGlTSDNHa ZjgK+vw7swccgHEdj/P173aPFvNX4+egRjh5zx3Itah5eUzG0a/DmZ77WstUieiDBzjeKDNDO8oVk DWzo/pvmtf8eyEVcEYJOQwK4PEYY/TCK0xWjcki+FQ9W5XAkHQ4fARZ8uJeFK+L2jM4kwTP1V0fWw vzvYtyyL1Y7w3U/WqhY+GyJcKvEQFDXHKIJcF/vLFKrA9rN7kYIbQ17Vwp5ML00RuEhOYub0c0jXR uJpzTq+OewkJ2f6nyr8pA/r5JA4+NSE2J1CqcTO2csIpPu7bOBRKXdJrUMO1xtplffEcfyVrvBPoM vXh/RMZZ6t5bhENWRtzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qVU9z-00GePY-0h; Mon, 14 Aug 2023 09:46:51 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qVU9u-00GeOu-13 for linux-arm-kernel@lists.infradead.org; Mon, 14 Aug 2023 09:46:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692006404; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=K4sGVUE43D+9dWlB8T8cOXLzUkJGkxQXnJLqjpcMDso=; b=cuVCw3IghSJoquXrlmBdW9mqCPeH3sMelFrcfOQBJcAkwPsfNeAvnvQ+v9Vyzx8i2bLd4Z 2TkzkUvRcMxR+HOeknAkTKtjHHr4252BR/flwDDN3vaU4iMSrrv4AUslsqiGZvXvZ45TY/ E8Md/h+dGCcvktYJrhI/weWkREEqYRM= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-59-V1JhcZPKNna7_WvWh_0YbA-1; Mon, 14 Aug 2023 05:46:42 -0400 X-MC-Unique: V1JhcZPKNna7_WvWh_0YbA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 299DD3815F62; Mon, 14 Aug 2023 09:46:41 +0000 (UTC) Received: from localhost (dhcp-192-239.str.redhat.com [10.33.192.239]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DC2D12166B25; Mon, 14 Aug 2023 09:46:40 +0000 (UTC) From: Cornelia Huck To: Jing Zhang , KVM , KVMARM , ARMLinux , Marc Zyngier , Oliver Upton Cc: Will Deacon , Paolo Bonzini , James Morse , Alexandru Elisei , Suzuki K Poulose , Fuad Tabba , Reiji Watanabe , Raghavendra Rao Ananta , Suraj Jitindar Singh , Jing Zhang Subject: Re: [PATCH v8 02/11] KVM: arm64: Document KVM_ARM_GET_REG_WRITABLE_MASKS In-Reply-To: <20230807162210.2528230-3-jingzhangos@google.com> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross" References: <20230807162210.2528230-1-jingzhangos@google.com> <20230807162210.2528230-3-jingzhangos@google.com> User-Agent: Notmuch/0.37 (https://notmuchmail.org) Date: Mon, 14 Aug 2023 11:46:39 +0200 Message-ID: <878raex8g0.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230814_024646_457100_87D5A237 X-CRM114-Status: GOOD ( 23.77 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Aug 07 2023, Jing Zhang wrote: > Add some basic documentation on how to get feature ID register writable > masks from userspace. > > Signed-off-by: Jing Zhang > --- > Documentation/virt/kvm/api.rst | 29 +++++++++++++++++++++++++++++ > 1 file changed, 29 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index c0ddd3035462..92a9b20f970e 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -6068,6 +6068,35 @@ writes to the CNTVCT_EL0 and CNTPCT_EL0 registers using the SET_ONE_REG > interface. No error will be returned, but the resulting offset will not be > applied. > > +4.139 KVM_ARM_GET_REG_WRITABLE_MASKS > +------------------------------------------- > + > +:Capability: none > +:Architectures: arm64 > +:Type: vm ioctl > +:Parameters: struct reg_mask_range (in/out) > +:Returns: 0 on success, < 0 on error > + > + > +:: > + > + #define ARM64_FEATURE_ID_SPACE_SIZE (3 * 8 * 8) > + > + struct reg_mask_range { > + __u64 addr; /* Pointer to mask array */ > + __u64 reserved[7]; > + }; > + > +This ioctl would copy the writable masks for feature ID registers to userspace. > +The Feature ID space is defined as the System register space in AArch64 with > +op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7}, op2=={0-7}. > +To get the index in the mask array pointed by ``addr`` for a specified feature > +ID register, use the macro ``ARM64_FEATURE_ID_SPACE_IDX(op0, op1, crn, crm, op2)``. > +This allows the userspace to know upfront whether it can actually tweak the > +contents of a feature ID register or not. > +The ``reserved[7]`` is reserved for future use to add other register space. For > +feature ID registers, it should be 0, otherwise, KVM may return error. In case of future extensions, this means that userspace needs to figure out what the kernel supports via different content in reg_mask_range (i.e. try with a value in one of the currently reserved fields and fall back to using addr only if that doesn't work.) Can we do better? Maybe we could introduce a capability that returns the supported ranges as flags, i.e. now we would return 1 for id regs masks, and for the future case where we have some values in the next reserved field we could return 1 & 2 etc. Would make life easier for userspace that needs to work with different kernels, but might be overkill if reserved[] is more like an insurance without any concrete plans for extensions. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel