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 X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60BBDC2B9F4 for ; Tue, 22 Jun 2021 10:35:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 46805613C3 for ; Tue, 22 Jun 2021 10:35:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229674AbhFVKhY (ORCPT ); Tue, 22 Jun 2021 06:37:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:46162 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229668AbhFVKhX (ORCPT ); Tue, 22 Jun 2021 06:37:23 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4096C613BE; Tue, 22 Jun 2021 10:35:08 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lvdkI-0094e6-Dg; Tue, 22 Jun 2021 11:35:06 +0100 Date: Tue, 22 Jun 2021 11:35:06 +0100 Message-ID: <874kdqchlx.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Steven Price , Catalin Marinas , Will Deacon , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Dave Martin , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Thomas Gleixner , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v17 6/6] KVM: arm64: Document MTE capability and ioctl In-Reply-To: References: <20210621111716.37157-1-steven.price@arm.com> <20210621111716.37157-7-steven.price@arm.com> 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/27.1 (x86_64-pc-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: tabba@google.com, steven.price@arm.com, catalin.marinas@arm.com, will@kernel.org, dgilbert@redhat.com, qemu-devel@nongnu.org, Dave.Martin@arm.com, quintela@redhat.com, richard.henderson@linaro.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 22 Jun 2021 10:42:42 +0100, Fuad Tabba wrote: > > Hi, > > > On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote: > > > > A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports > > granting a guest access to the tags, and provides a mechanism for the > > VMM to enable it. > > > > A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to > > access the tags of a guest without having to maintain a PROT_MTE mapping > > in userspace. The above capability gates access to the ioctl. > > > > Reviewed-by: Catalin Marinas > > Signed-off-by: Steven Price > > --- > > Documentation/virt/kvm/api.rst | 61 ++++++++++++++++++++++++++++++++++ > > 1 file changed, 61 insertions(+) > > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > > index 7fcb2fd38f42..97661a97943f 100644 > > --- a/Documentation/virt/kvm/api.rst > > +++ b/Documentation/virt/kvm/api.rst > > @@ -5034,6 +5034,43 @@ see KVM_XEN_VCPU_SET_ATTR above. > > The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used > > with the KVM_XEN_VCPU_GET_ATTR ioctl. > > > > +4.130 KVM_ARM_MTE_COPY_TAGS > > +--------------------------- > > + > > +:Capability: KVM_CAP_ARM_MTE > > +:Architectures: arm64 > > +:Type: vm ioctl > > +:Parameters: struct kvm_arm_copy_mte_tags > > +:Returns: number of bytes copied, < 0 on error (-EINVAL for incorrect > > + arguments, -EFAULT if memory cannot be accessed). > > + > > +:: > > + > > + struct kvm_arm_copy_mte_tags { > > + __u64 guest_ipa; > > + __u64 length; > > + void __user *addr; > > + __u64 flags; > > + __u64 reserved[2]; > > + }; > > + > > +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The > > +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr`` > > +field must point to a buffer which the tags will be copied to or from. > > + > > +``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or > > +``KVM_ARM_TAGS_FROM_GUEST``. > > + > > +The size of the buffer to store the tags is ``(length / 16)`` bytes > > +(granules in MTE are 16 bytes long). Each byte contains a single tag > > +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and > > +``PTRACE_POKEMTETAGS``. > > + > > +If an error occurs before any data is copied then a negative error code is > > +returned. If some tags have been copied before an error occurs then the number > > +of bytes successfully copied is returned. If the call completes successfully > > +then ``length`` is returned. > > + > > 5. The kvm_run structure > > ======================== > > > > @@ -6362,6 +6399,30 @@ default. > > > > See Documentation/x86/sgx/2.Kernel-internals.rst for more details. > > > > +7.26 KVM_CAP_ARM_MTE > > +-------------------- > > + > > +:Architectures: arm64 > > +:Parameters: none > > + > > +This capability indicates that KVM (and the hardware) supports exposing the > > +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the > > +VMM before creating any VCPUs to allow the guest access. Note that MTE is only > > +available to a guest running in AArch64 mode and enabling this capability will > > +cause attempts to create AArch32 VCPUs to fail. > > I was wondering if there might be an issue with AArch32 at EL0 and > MTE, because I think that even if AArch64 at EL1 is disallowed, the Did you mean AArch32 here? > guest can still run AArch32 at EL0. I don't get your question: - If the guest is AArch32 at EL1, there is not MTE whatsoever (where would you place the tag?) - If the guest is AArch64, it can have MTE enabled or not, irrespective of the EL. If this guest decides to run an AArch32 EL0, the architecture rules still apply, and it cannot expose MTE to its own 32bit userspace. Nothing that KVM needs to do about this. What KVM enforces is that at the point where the guest is in charge, we have a consistent architectural behaviour. Thanks, M. -- Without deviation from the norm, progress is not possible. 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 X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B65FC48BE5 for ; Tue, 22 Jun 2021 10:37:39 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B8D36613BE for ; Tue, 22 Jun 2021 10:37:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B8D36613BE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:37994 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lvdmj-0000Sb-TN for qemu-devel@archiver.kernel.org; Tue, 22 Jun 2021 06:37:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48924) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvdkP-00068n-Hd for qemu-devel@nongnu.org; Tue, 22 Jun 2021 06:35:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:34870) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvdkM-0008BL-UH for qemu-devel@nongnu.org; Tue, 22 Jun 2021 06:35:12 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4096C613BE; Tue, 22 Jun 2021 10:35:08 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lvdkI-0094e6-Dg; Tue, 22 Jun 2021 11:35:06 +0100 Date: Tue, 22 Jun 2021 11:35:06 +0100 Message-ID: <874kdqchlx.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Subject: Re: [PATCH v17 6/6] KVM: arm64: Document MTE capability and ioctl In-Reply-To: References: <20210621111716.37157-1-steven.price@arm.com> <20210621111716.37157-7-steven.price@arm.com> 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/27.1 (x86_64-pc-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: tabba@google.com, steven.price@arm.com, catalin.marinas@arm.com, will@kernel.org, dgilbert@redhat.com, qemu-devel@nongnu.org, Dave.Martin@arm.com, quintela@redhat.com, richard.henderson@linaro.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Received-SPF: pass client-ip=198.145.29.99; envelope-from=maz@kernel.org; helo=mail.kernel.org X-Spam_score_int: -68 X-Spam_score: -6.9 X-Spam_bar: ------ X-Spam_report: (-6.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juan Quintela , Catalin Marinas , Richard Henderson , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Steven Price , Will Deacon , Dave Martin , linux-kernel@vger.kernel.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, 22 Jun 2021 10:42:42 +0100, Fuad Tabba wrote: > > Hi, > > > On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote: > > > > A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports > > granting a guest access to the tags, and provides a mechanism for the > > VMM to enable it. > > > > A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to > > access the tags of a guest without having to maintain a PROT_MTE mapping > > in userspace. The above capability gates access to the ioctl. > > > > Reviewed-by: Catalin Marinas > > Signed-off-by: Steven Price > > --- > > Documentation/virt/kvm/api.rst | 61 ++++++++++++++++++++++++++++++++++ > > 1 file changed, 61 insertions(+) > > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > > index 7fcb2fd38f42..97661a97943f 100644 > > --- a/Documentation/virt/kvm/api.rst > > +++ b/Documentation/virt/kvm/api.rst > > @@ -5034,6 +5034,43 @@ see KVM_XEN_VCPU_SET_ATTR above. > > The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used > > with the KVM_XEN_VCPU_GET_ATTR ioctl. > > > > +4.130 KVM_ARM_MTE_COPY_TAGS > > +--------------------------- > > + > > +:Capability: KVM_CAP_ARM_MTE > > +:Architectures: arm64 > > +:Type: vm ioctl > > +:Parameters: struct kvm_arm_copy_mte_tags > > +:Returns: number of bytes copied, < 0 on error (-EINVAL for incorrect > > + arguments, -EFAULT if memory cannot be accessed). > > + > > +:: > > + > > + struct kvm_arm_copy_mte_tags { > > + __u64 guest_ipa; > > + __u64 length; > > + void __user *addr; > > + __u64 flags; > > + __u64 reserved[2]; > > + }; > > + > > +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The > > +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr`` > > +field must point to a buffer which the tags will be copied to or from. > > + > > +``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or > > +``KVM_ARM_TAGS_FROM_GUEST``. > > + > > +The size of the buffer to store the tags is ``(length / 16)`` bytes > > +(granules in MTE are 16 bytes long). Each byte contains a single tag > > +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and > > +``PTRACE_POKEMTETAGS``. > > + > > +If an error occurs before any data is copied then a negative error code is > > +returned. If some tags have been copied before an error occurs then the number > > +of bytes successfully copied is returned. If the call completes successfully > > +then ``length`` is returned. > > + > > 5. The kvm_run structure > > ======================== > > > > @@ -6362,6 +6399,30 @@ default. > > > > See Documentation/x86/sgx/2.Kernel-internals.rst for more details. > > > > +7.26 KVM_CAP_ARM_MTE > > +-------------------- > > + > > +:Architectures: arm64 > > +:Parameters: none > > + > > +This capability indicates that KVM (and the hardware) supports exposing the > > +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the > > +VMM before creating any VCPUs to allow the guest access. Note that MTE is only > > +available to a guest running in AArch64 mode and enabling this capability will > > +cause attempts to create AArch32 VCPUs to fail. > > I was wondering if there might be an issue with AArch32 at EL0 and > MTE, because I think that even if AArch64 at EL1 is disallowed, the Did you mean AArch32 here? > guest can still run AArch32 at EL0. I don't get your question: - If the guest is AArch32 at EL1, there is not MTE whatsoever (where would you place the tag?) - If the guest is AArch64, it can have MTE enabled or not, irrespective of the EL. If this guest decides to run an AArch32 EL0, the architecture rules still apply, and it cannot expose MTE to its own 32bit userspace. Nothing that KVM needs to do about this. What KVM enforces is that at the point where the guest is in charge, we have a consistent architectural behaviour. Thanks, M. -- Without deviation from the norm, progress is not possible. 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 X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6705FC2B9F4 for ; Tue, 22 Jun 2021 10:35:15 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id DE58E613C5 for ; Tue, 22 Jun 2021 10:35:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DE58E613C5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5B7B3407B0; Tue, 22 Jun 2021 06:35:14 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qq-FGHNMJBm; Tue, 22 Jun 2021 06:35:12 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 476364029C; Tue, 22 Jun 2021 06:35:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 795EF407B0 for ; Tue, 22 Jun 2021 06:35:10 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksWBI9u8jJTY for ; Tue, 22 Jun 2021 06:35:09 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 36BBD40256 for ; Tue, 22 Jun 2021 06:35:09 -0400 (EDT) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4096C613BE; Tue, 22 Jun 2021 10:35:08 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lvdkI-0094e6-Dg; Tue, 22 Jun 2021 11:35:06 +0100 Date: Tue, 22 Jun 2021 11:35:06 +0100 Message-ID: <874kdqchlx.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Subject: Re: [PATCH v17 6/6] KVM: arm64: Document MTE capability and ioctl In-Reply-To: References: <20210621111716.37157-1-steven.price@arm.com> <20210621111716.37157-7-steven.price@arm.com> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: tabba@google.com, steven.price@arm.com, catalin.marinas@arm.com, will@kernel.org, dgilbert@redhat.com, qemu-devel@nongnu.org, Dave.Martin@arm.com, quintela@redhat.com, richard.henderson@linaro.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: Juan Quintela , Catalin Marinas , Richard Henderson , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Steven Price , Will Deacon , Dave Martin , linux-kernel@vger.kernel.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Tue, 22 Jun 2021 10:42:42 +0100, Fuad Tabba wrote: > > Hi, > > > On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote: > > > > A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports > > granting a guest access to the tags, and provides a mechanism for the > > VMM to enable it. > > > > A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to > > access the tags of a guest without having to maintain a PROT_MTE mapping > > in userspace. The above capability gates access to the ioctl. > > > > Reviewed-by: Catalin Marinas > > Signed-off-by: Steven Price > > --- > > Documentation/virt/kvm/api.rst | 61 ++++++++++++++++++++++++++++++++++ > > 1 file changed, 61 insertions(+) > > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > > index 7fcb2fd38f42..97661a97943f 100644 > > --- a/Documentation/virt/kvm/api.rst > > +++ b/Documentation/virt/kvm/api.rst > > @@ -5034,6 +5034,43 @@ see KVM_XEN_VCPU_SET_ATTR above. > > The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used > > with the KVM_XEN_VCPU_GET_ATTR ioctl. > > > > +4.130 KVM_ARM_MTE_COPY_TAGS > > +--------------------------- > > + > > +:Capability: KVM_CAP_ARM_MTE > > +:Architectures: arm64 > > +:Type: vm ioctl > > +:Parameters: struct kvm_arm_copy_mte_tags > > +:Returns: number of bytes copied, < 0 on error (-EINVAL for incorrect > > + arguments, -EFAULT if memory cannot be accessed). > > + > > +:: > > + > > + struct kvm_arm_copy_mte_tags { > > + __u64 guest_ipa; > > + __u64 length; > > + void __user *addr; > > + __u64 flags; > > + __u64 reserved[2]; > > + }; > > + > > +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The > > +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr`` > > +field must point to a buffer which the tags will be copied to or from. > > + > > +``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or > > +``KVM_ARM_TAGS_FROM_GUEST``. > > + > > +The size of the buffer to store the tags is ``(length / 16)`` bytes > > +(granules in MTE are 16 bytes long). Each byte contains a single tag > > +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and > > +``PTRACE_POKEMTETAGS``. > > + > > +If an error occurs before any data is copied then a negative error code is > > +returned. If some tags have been copied before an error occurs then the number > > +of bytes successfully copied is returned. If the call completes successfully > > +then ``length`` is returned. > > + > > 5. The kvm_run structure > > ======================== > > > > @@ -6362,6 +6399,30 @@ default. > > > > See Documentation/x86/sgx/2.Kernel-internals.rst for more details. > > > > +7.26 KVM_CAP_ARM_MTE > > +-------------------- > > + > > +:Architectures: arm64 > > +:Parameters: none > > + > > +This capability indicates that KVM (and the hardware) supports exposing the > > +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the > > +VMM before creating any VCPUs to allow the guest access. Note that MTE is only > > +available to a guest running in AArch64 mode and enabling this capability will > > +cause attempts to create AArch32 VCPUs to fail. > > I was wondering if there might be an issue with AArch32 at EL0 and > MTE, because I think that even if AArch64 at EL1 is disallowed, the Did you mean AArch32 here? > guest can still run AArch32 at EL0. I don't get your question: - If the guest is AArch32 at EL1, there is not MTE whatsoever (where would you place the tag?) - If the guest is AArch64, it can have MTE enabled or not, irrespective of the EL. If this guest decides to run an AArch32 EL0, the architecture rules still apply, and it cannot expose MTE to its own 32bit userspace. Nothing that KVM needs to do about this. What KVM enforces is that at the point where the guest is in charge, we have a consistent architectural behaviour. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 X-Spam-Level: X-Spam-Status: No, score=-14.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B180AC2B9F4 for ; Tue, 22 Jun 2021 10:36:59 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 7DA68613BE for ; Tue, 22 Jun 2021 10:36:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DA68613BE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EWVLWWWj0NBflcvYFqqWM4sYGnHuTAOoOU3jTq74Jsw=; b=SQVFWc78dY/Syz N1VGjnIhFxzo2w4BfYLbOugsxSJ91AFQpTCrS/LsQX1QMdtxhXBQuXoODU24KO1XuAfloCUVhqd3r veKQCi/qFdyamJzC73v9hHiVGhcetgBu9OrrOZWy60rOJe/2swo39278sKeYdD5Csotv9o4pwrgq5 KRnWkJTCiYYuEEMwxRc838gC+PC7fXRbZBYGvWorPYV5a5gK/XB+tGeUGPPL4/FReHJfLW8nPELuo y9z5sxTjeLipszugc1tM7rDR/3YZh8bDbbEpXMTlYHH109Ap0vVVlt0FVtD7wWbrb73HjN9GPXgSr j9UOxpmMXaGoXnL9we7w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvdkP-006gxC-4e; Tue, 22 Jun 2021 10:35:13 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvdkK-006gvV-Ft for linux-arm-kernel@lists.infradead.org; Tue, 22 Jun 2021 10:35:10 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4096C613BE; Tue, 22 Jun 2021 10:35:08 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lvdkI-0094e6-Dg; Tue, 22 Jun 2021 11:35:06 +0100 Date: Tue, 22 Jun 2021 11:35:06 +0100 Message-ID: <874kdqchlx.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Steven Price , Catalin Marinas , Will Deacon , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Dave Martin , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Thomas Gleixner , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v17 6/6] KVM: arm64: Document MTE capability and ioctl In-Reply-To: References: <20210621111716.37157-1-steven.price@arm.com> <20210621111716.37157-7-steven.price@arm.com> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: tabba@google.com, steven.price@arm.com, catalin.marinas@arm.com, will@kernel.org, dgilbert@redhat.com, qemu-devel@nongnu.org, Dave.Martin@arm.com, quintela@redhat.com, richard.henderson@linaro.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.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-20210622_033508_612940_DF91EC2F X-CRM114-Status: GOOD ( 40.71 ) 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 Tue, 22 Jun 2021 10:42:42 +0100, Fuad Tabba wrote: > > Hi, > > > On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote: > > > > A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports > > granting a guest access to the tags, and provides a mechanism for the > > VMM to enable it. > > > > A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to > > access the tags of a guest without having to maintain a PROT_MTE mapping > > in userspace. The above capability gates access to the ioctl. > > > > Reviewed-by: Catalin Marinas > > Signed-off-by: Steven Price > > --- > > Documentation/virt/kvm/api.rst | 61 ++++++++++++++++++++++++++++++++++ > > 1 file changed, 61 insertions(+) > > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > > index 7fcb2fd38f42..97661a97943f 100644 > > --- a/Documentation/virt/kvm/api.rst > > +++ b/Documentation/virt/kvm/api.rst > > @@ -5034,6 +5034,43 @@ see KVM_XEN_VCPU_SET_ATTR above. > > The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used > > with the KVM_XEN_VCPU_GET_ATTR ioctl. > > > > +4.130 KVM_ARM_MTE_COPY_TAGS > > +--------------------------- > > + > > +:Capability: KVM_CAP_ARM_MTE > > +:Architectures: arm64 > > +:Type: vm ioctl > > +:Parameters: struct kvm_arm_copy_mte_tags > > +:Returns: number of bytes copied, < 0 on error (-EINVAL for incorrect > > + arguments, -EFAULT if memory cannot be accessed). > > + > > +:: > > + > > + struct kvm_arm_copy_mte_tags { > > + __u64 guest_ipa; > > + __u64 length; > > + void __user *addr; > > + __u64 flags; > > + __u64 reserved[2]; > > + }; > > + > > +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The > > +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr`` > > +field must point to a buffer which the tags will be copied to or from. > > + > > +``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or > > +``KVM_ARM_TAGS_FROM_GUEST``. > > + > > +The size of the buffer to store the tags is ``(length / 16)`` bytes > > +(granules in MTE are 16 bytes long). Each byte contains a single tag > > +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and > > +``PTRACE_POKEMTETAGS``. > > + > > +If an error occurs before any data is copied then a negative error code is > > +returned. If some tags have been copied before an error occurs then the number > > +of bytes successfully copied is returned. If the call completes successfully > > +then ``length`` is returned. > > + > > 5. The kvm_run structure > > ======================== > > > > @@ -6362,6 +6399,30 @@ default. > > > > See Documentation/x86/sgx/2.Kernel-internals.rst for more details. > > > > +7.26 KVM_CAP_ARM_MTE > > +-------------------- > > + > > +:Architectures: arm64 > > +:Parameters: none > > + > > +This capability indicates that KVM (and the hardware) supports exposing the > > +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the > > +VMM before creating any VCPUs to allow the guest access. Note that MTE is only > > +available to a guest running in AArch64 mode and enabling this capability will > > +cause attempts to create AArch32 VCPUs to fail. > > I was wondering if there might be an issue with AArch32 at EL0 and > MTE, because I think that even if AArch64 at EL1 is disallowed, the Did you mean AArch32 here? > guest can still run AArch32 at EL0. I don't get your question: - If the guest is AArch32 at EL1, there is not MTE whatsoever (where would you place the tag?) - If the guest is AArch64, it can have MTE enabled or not, irrespective of the EL. If this guest decides to run an AArch32 EL0, the architecture rules still apply, and it cannot expose MTE to its own 32bit userspace. Nothing that KVM needs to do about this. What KVM enforces is that at the point where the guest is in charge, we have a consistent architectural behaviour. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel