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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 36442C47094 for ; Mon, 7 Jun 2021 17:32:25 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 9C0C6610A1 for ; Mon, 7 Jun 2021 17:32:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C0C6610A1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com 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 2465140878; Mon, 7 Jun 2021 13:32:24 -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 oB-G34-qNfuV; Mon, 7 Jun 2021 13:32:22 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DE9E9407EF; Mon, 7 Jun 2021 13:32:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B7C2A407EF for ; Mon, 7 Jun 2021 13:32:21 -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 B+LsA+eMt9SA for ; Mon, 7 Jun 2021 13:32:20 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 5F24F4079A for ; Mon, 7 Jun 2021 13:32:20 -0400 (EDT) Received: by mail.kernel.org (Postfix) with ESMTPSA id 7871661090; Mon, 7 Jun 2021 17:32:16 +0000 (UTC) Date: Mon, 7 Jun 2021 18:32:14 +0100 From: Catalin Marinas To: Steven Price Subject: Re: [PATCH v14 8/8] KVM: arm64: Document MTE capability and ioctl Message-ID: <20210607173213.GC17957@arm.com> References: <20210607110816.25762-1-steven.price@arm.com> <20210607110816.25762-9-steven.price@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210607110816.25762-9-steven.price@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Cc: "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Marc Zyngier , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu 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 Mon, Jun 07, 2021 at 12:08:16PM +0100, Steven Price wrote: > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 22d077562149..fc6f0cbc30b3 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -5034,6 +5034,42 @@ 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 I guess you can be a bit more specific here, -EINVAL on incorrect arguments, -EFAULT if the guest 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`` > +fieldmust point to a buffer which the tags will be copied to or from. s/fieldmust/field must/ > + > +``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``. One difference I think with ptrace() is that iov_len (length here) is the actual buffer size. But for kvm I think this works better since length is tied to the guest_ipa. > + > +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 +6398,27 @@ 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. > + > +When enabled the guest is able to access tags associated with any memory given > +to the guest. KVM will ensure that the pages are flagged ``PG_mte_tagged`` so > +that the tags are maintained during swap or hibernation of the host; however I'd drop PG_mte_tagged here, that's just how the implementation handles it, not necessary for describing the API. You can just say "KVM will ensure that the tags are maintained during swap or hibernation of the host" > +the VMM needs to manually save/restore the tags as appropriate if the VM is > +migrated. > + > +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to > +perform a bulk copy of tags to/from the guest. > + > 8. Other capabilities. > ====================== > > -- > 2.20.1 Otherwise, feel free to add: Reviewed-by: Catalin Marinas _______________________________________________ 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=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 BA1E4C47082 for ; Mon, 7 Jun 2021 17:37:10 +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 839F86109F for ; Mon, 7 Jun 2021 17:37:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 839F86109F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=X4hRdzmugdJBc1rfQX6RQkesi/hhPMtqqzPk9JAM84I=; b=41Kdg9ypNILM4d UwKXi2F+lQlVCtb73hUyz7TbTO8sdciBfUBJ0Ez7Nx/Je0my2hygzqtJ0Aeh9ftRDlgh/yKV+LJFc aVPu9K9kDAgw8ocEV5IGJuNxpXpJsBRixlxD8XmrrzrAr992J4ry9KWNbdGy5LllcyMpnFK7rezsJ AyaBJHGsEeD93Ij/zG8uQwDkhw2p693KKgo01EtQuXJMyvZGFAUwuUbpzJq7YFz8Gps3c6ClI2aVe 9/AAIkcquVD9h7mVIiDZvchvGs+hASqn/g6Yry+dhna1Gvitf70zgpmFx8kuoYMuYQCHkmtIy/cnH mr2SP1sMSmU+djAYOOhQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqJ9i-004qMH-3g; Mon, 07 Jun 2021 17:35:18 +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 1lqJ6p-004pJi-NG for linux-arm-kernel@lists.infradead.org; Mon, 07 Jun 2021 17:32:21 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7871661090; Mon, 7 Jun 2021 17:32:16 +0000 (UTC) Date: Mon, 7 Jun 2021 18:32:14 +0100 From: Catalin Marinas To: Steven Price Cc: Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , Mark Rutland , Thomas Gleixner , qemu-devel@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Peter Maydell , Haibo Xu , Andrew Jones Subject: Re: [PATCH v14 8/8] KVM: arm64: Document MTE capability and ioctl Message-ID: <20210607173213.GC17957@arm.com> References: <20210607110816.25762-1-steven.price@arm.com> <20210607110816.25762-9-steven.price@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210607110816.25762-9-steven.price@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210607_103219_833167_EA591D2C X-CRM114-Status: GOOD ( 26.90 ) 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, Jun 07, 2021 at 12:08:16PM +0100, Steven Price wrote: > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 22d077562149..fc6f0cbc30b3 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -5034,6 +5034,42 @@ 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 I guess you can be a bit more specific here, -EINVAL on incorrect arguments, -EFAULT if the guest 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`` > +fieldmust point to a buffer which the tags will be copied to or from. s/fieldmust/field must/ > + > +``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``. One difference I think with ptrace() is that iov_len (length here) is the actual buffer size. But for kvm I think this works better since length is tied to the guest_ipa. > + > +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 +6398,27 @@ 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. > + > +When enabled the guest is able to access tags associated with any memory given > +to the guest. KVM will ensure that the pages are flagged ``PG_mte_tagged`` so > +that the tags are maintained during swap or hibernation of the host; however I'd drop PG_mte_tagged here, that's just how the implementation handles it, not necessary for describing the API. You can just say "KVM will ensure that the tags are maintained during swap or hibernation of the host" > +the VMM needs to manually save/restore the tags as appropriate if the VM is > +migrated. > + > +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to > +perform a bulk copy of tags to/from the guest. > + > 8. Other capabilities. > ====================== > > -- > 2.20.1 Otherwise, feel free to add: Reviewed-by: Catalin Marinas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 D348FC47082 for ; Mon, 7 Jun 2021 17:32:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BAE54610A8 for ; Mon, 7 Jun 2021 17:32:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231474AbhFGReM (ORCPT ); Mon, 7 Jun 2021 13:34:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:59578 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231177AbhFGReK (ORCPT ); Mon, 7 Jun 2021 13:34:10 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7871661090; Mon, 7 Jun 2021 17:32:16 +0000 (UTC) Date: Mon, 7 Jun 2021 18:32:14 +0100 From: Catalin Marinas To: Steven Price Cc: Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , Mark Rutland , Thomas Gleixner , qemu-devel@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Peter Maydell , Haibo Xu , Andrew Jones Subject: Re: [PATCH v14 8/8] KVM: arm64: Document MTE capability and ioctl Message-ID: <20210607173213.GC17957@arm.com> References: <20210607110816.25762-1-steven.price@arm.com> <20210607110816.25762-9-steven.price@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210607110816.25762-9-steven.price@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 07, 2021 at 12:08:16PM +0100, Steven Price wrote: > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 22d077562149..fc6f0cbc30b3 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -5034,6 +5034,42 @@ 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 I guess you can be a bit more specific here, -EINVAL on incorrect arguments, -EFAULT if the guest 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`` > +fieldmust point to a buffer which the tags will be copied to or from. s/fieldmust/field must/ > + > +``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``. One difference I think with ptrace() is that iov_len (length here) is the actual buffer size. But for kvm I think this works better since length is tied to the guest_ipa. > + > +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 +6398,27 @@ 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. > + > +When enabled the guest is able to access tags associated with any memory given > +to the guest. KVM will ensure that the pages are flagged ``PG_mte_tagged`` so > +that the tags are maintained during swap or hibernation of the host; however I'd drop PG_mte_tagged here, that's just how the implementation handles it, not necessary for describing the API. You can just say "KVM will ensure that the tags are maintained during swap or hibernation of the host" > +the VMM needs to manually save/restore the tags as appropriate if the VM is > +migrated. > + > +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to > +perform a bulk copy of tags to/from the guest. > + > 8. Other capabilities. > ====================== > > -- > 2.20.1 Otherwise, feel free to add: Reviewed-by: Catalin Marinas 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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 4C1C8C47094 for ; Mon, 7 Jun 2021 17:59:53 +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 0321E610FB for ; Mon, 7 Jun 2021 17:59:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0321E610FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:36022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqJXU-0004if-1a for qemu-devel@archiver.kernel.org; Mon, 07 Jun 2021 13:59:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqJ6t-0002sR-8h for qemu-devel@nongnu.org; Mon, 07 Jun 2021 13:32:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:48280) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqJ6q-0005L9-OW for qemu-devel@nongnu.org; Mon, 07 Jun 2021 13:32:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7871661090; Mon, 7 Jun 2021 17:32:16 +0000 (UTC) Date: Mon, 7 Jun 2021 18:32:14 +0100 From: Catalin Marinas To: Steven Price Subject: Re: [PATCH v14 8/8] KVM: arm64: Document MTE capability and ioctl Message-ID: <20210607173213.GC17957@arm.com> References: <20210607110816.25762-1-steven.price@arm.com> <20210607110816.25762-9-steven.price@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210607110816.25762-9-steven.price@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: pass client-ip=198.145.29.99; envelope-from=cmarinas@kernel.org; helo=mail.kernel.org X-Spam_score_int: -66 X-Spam_score: -6.7 X-Spam_bar: ------ X-Spam_report: (-6.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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: Mark Rutland , Peter Maydell , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , qemu-devel@nongnu.org, Marc Zyngier , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , James Morse , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, Jun 07, 2021 at 12:08:16PM +0100, Steven Price wrote: > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 22d077562149..fc6f0cbc30b3 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -5034,6 +5034,42 @@ 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 I guess you can be a bit more specific here, -EINVAL on incorrect arguments, -EFAULT if the guest 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`` > +fieldmust point to a buffer which the tags will be copied to or from. s/fieldmust/field must/ > + > +``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``. One difference I think with ptrace() is that iov_len (length here) is the actual buffer size. But for kvm I think this works better since length is tied to the guest_ipa. > + > +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 +6398,27 @@ 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. > + > +When enabled the guest is able to access tags associated with any memory given > +to the guest. KVM will ensure that the pages are flagged ``PG_mte_tagged`` so > +that the tags are maintained during swap or hibernation of the host; however I'd drop PG_mte_tagged here, that's just how the implementation handles it, not necessary for describing the API. You can just say "KVM will ensure that the tags are maintained during swap or hibernation of the host" > +the VMM needs to manually save/restore the tags as appropriate if the VM is > +migrated. > + > +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to > +perform a bulk copy of tags to/from the guest. > + > 8. Other capabilities. > ====================== > > -- > 2.20.1 Otherwise, feel free to add: Reviewed-by: Catalin Marinas