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.