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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 23F22C4332E for ; Tue, 9 Mar 2021 11:02:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EECEA6525D for ; Tue, 9 Mar 2021 11:02:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230183AbhCILCD (ORCPT ); Tue, 9 Mar 2021 06:02:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229948AbhCILBq (ORCPT ); Tue, 9 Mar 2021 06:01:46 -0500 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4C74C06174A for ; Tue, 9 Mar 2021 03:01:45 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id h10so19245756edl.6 for ; Tue, 09 Mar 2021 03:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vdZ4o+zoeGhBm3eWUzEKAm3SjsyvDpQ7XHjJEgZbpvA=; b=mLLgcOkGiUnzFw3UE3oQBVac/QperD9HatYPiTHaHcjhWXjSDD9xGqDW9WAKvrfswy 12Kaqb8Mxo0fSaxpDqm5TJki2Vs+jTW3433sX1ZHcUJ2m4/Pi8FnaoAW78pwEm2X2erO 8fRS7lCr/tep5XCTaV5V8csBu2hfOkYN7lB7rNFPcE42icw/QkJvQMHzxIFuBAyUjAKG INrt/uotzmU+770iB07TJu/T//V7mQ1Qt4g/7OPcU5T2DXTKnmMfH8FkMRcC01sKh52i FJwt39CTqR9mmdQ4vly4YFUdfl8mt8Hy/tDK5ys81SjtV9JAkLVYUbJnVwi+M/VNYQMN 5TUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vdZ4o+zoeGhBm3eWUzEKAm3SjsyvDpQ7XHjJEgZbpvA=; b=aVafbfSYwmyyoIOZJF4qUExNi4uAEb51SpmJDdZXgKWy5uUh86457C3ahozxth7wNt p6kF0xgDndsmbr5TMKVOI6AIBupnA49Ol5VIqjrYJXeqhP6bKiIVxNebhMNfBZwTRWug h8+CcwoEsreYP6sfwepSbOS6A4sSE91YLrW9MZdGY276oJvglnHqTPPSqaiJnfijYGvm gMsDlLblKfxtwNjtIn8cBBcwuBKa6R786jCuShdqCSPKIuJaKmGAzd6e6GwuS9eUkzln 0fCbdQLaXpuiZRGgnA02+oRCm7cLZkaUt8JGQwWLOEz9ZFsiDB3J8bQ99G7RO9+ZEJ7l T+cQ== X-Gm-Message-State: AOAM533vX3wAPo7TgZwhcCYf9fR/6RK6mZJpohRHFGmpjzEo7IFrIw2V W5SivRWXyzEUvXSVcVd6aB9tufZFQBs9WIlhp1Ph0g== X-Google-Smtp-Source: ABdhPJxklFVbfFNwNwAAaKz6vbxUZ69o/Z0+23/AeFD9ENbDqkgki+Ljib01MLFfq9nwJFRwK6T2DanfvfvyeHNfctY= X-Received: by 2002:a05:6402:19a:: with SMTP id r26mr3358969edv.44.1615287704169; Tue, 09 Mar 2021 03:01:44 -0800 (PST) MIME-Version: 1.0 References: <20210301142315.30920-1-steven.price@arm.com> <20210301142315.30920-7-steven.price@arm.com> In-Reply-To: <20210301142315.30920-7-steven.price@arm.com> From: Peter Maydell Date: Tue, 9 Mar 2021 11:01:27 +0000 Message-ID: Subject: Re: [PATCH v9 6/6] KVM: arm64: Document MTE capability and ioctl To: Steven Price Cc: Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm , arm-mail-list , lkml - Kernel Mailing List , Dave Martin , Mark Rutland , Thomas Gleixner , QEMU Developers , Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Haibo Xu , Andrew Jones Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 1 Mar 2021 at 14:23, 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. > > Signed-off-by: Steven Price > --- > Documentation/virt/kvm/api.rst | 37 ++++++++++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index aed52b0fc16e..1406ea138127 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -4939,6 +4939,23 @@ KVM_XEN_VCPU_ATTR_TYPE_VCPU_TIME_INFO > Allows Xen vCPU attributes to be read. For the structure and types, > see KVM_XEN_VCPU_SET_ATTR above. > > +4.131 KVM_ARM_MTE_COPY_TAGS > +--------------------------- > + > +:Capability: KVM_CAP_ARM_MTE > +:Architectures: arm64 > +:Type: vm ioctl > +:Parameters: struct kvm_arm_copy_mte_tags > +:Returns: 0 on success, < 0 on error > + > +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. Mostly virt/kvm/api.rst seems to include documentation of the associated structs, something like: :: struct kvm_arm_copy_mte_tags { __u64 guest_ipa; __u64 length; union { void __user *addr; __u64 padding; }; __u64 flags; }; which saves the reader having to cross-reference against the header file. It also means you can more naturally use the actual field names in the doc, eg: > +The > +starting address and length of guest memory must be ``PAGE_SIZE`` aligned. you could say "The guest_ipa and length fields" here. Also "The addr field must point to a buffer which the tags will be copied to or from." I assume. > +The size of the buffer to store the tags is ``(length / MTE_GRANULE_SIZE)`` > +bytes (i.e. 1/16th of the corresponding size). > + Each byte contains a single tag > +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and > +``PTRACE_POKEMTETAGS``. What are the valid values for 'flags' ? It looks like they specify which direction the copy is, which we definitely need to document here. What happens if the caller requests a tag copy for an area of guest address space which doesn't have tags (eg it has nothing mapped), or for an area of guest addres space which has tags in some parts but not in others ? > + > 5. The kvm_run structure > ======================== > > @@ -6227,6 +6244,25 @@ KVM_RUN_BUS_LOCK flag is used to distinguish between them. > This capability can be used to check / enable 2nd DAWR feature provided > by POWER10 processor. > > +7.23 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 the guest will be granted access. > + > +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 s/,/;/ > +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 "guest." > + > 8. Other capabilities. > ====================== > > @@ -6716,3 +6752,4 @@ KVM_XEN_HVM_SET_ATTR, KVM_XEN_HVM_GET_ATTR, KVM_XEN_VCPU_SET_ATTR and > KVM_XEN_VCPU_GET_ATTR ioctls, as well as the delivery of exception vectors > for event channel upcalls when the evtchn_upcall_pending field of a vcpu's > vcpu_info is set. > + > -- > 2.20.1 Stray whitespace change ? thanks -- PMM 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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B65EAC433E6 for ; Tue, 9 Mar 2021 11:07:10 +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 4D89A6524C for ; Tue, 9 Mar 2021 11:07:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D89A6524C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:60890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJaCj-00021j-7X for qemu-devel@archiver.kernel.org; Tue, 09 Mar 2021 06:07:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58366) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJa7Y-00051X-RV for qemu-devel@nongnu.org; Tue, 09 Mar 2021 06:01:48 -0500 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:36401) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJa7W-00070h-EB for qemu-devel@nongnu.org; Tue, 09 Mar 2021 06:01:48 -0500 Received: by mail-ed1-x532.google.com with SMTP id l12so19268118edt.3 for ; Tue, 09 Mar 2021 03:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vdZ4o+zoeGhBm3eWUzEKAm3SjsyvDpQ7XHjJEgZbpvA=; b=mLLgcOkGiUnzFw3UE3oQBVac/QperD9HatYPiTHaHcjhWXjSDD9xGqDW9WAKvrfswy 12Kaqb8Mxo0fSaxpDqm5TJki2Vs+jTW3433sX1ZHcUJ2m4/Pi8FnaoAW78pwEm2X2erO 8fRS7lCr/tep5XCTaV5V8csBu2hfOkYN7lB7rNFPcE42icw/QkJvQMHzxIFuBAyUjAKG INrt/uotzmU+770iB07TJu/T//V7mQ1Qt4g/7OPcU5T2DXTKnmMfH8FkMRcC01sKh52i FJwt39CTqR9mmdQ4vly4YFUdfl8mt8Hy/tDK5ys81SjtV9JAkLVYUbJnVwi+M/VNYQMN 5TUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vdZ4o+zoeGhBm3eWUzEKAm3SjsyvDpQ7XHjJEgZbpvA=; b=Vk8BSWdYYNCtdPMLkokLvEx8CPemKwwOr3Eg+8XRXzWyEozFwbwvWf087W8ar6lnhy KCINPkgEY1OLUqNENhNqoAlUgm/d5RDLyMTCJsqhPGp6Xdk5gQXaNGOrY73N4nx7B663 Fn8506kVOBLztlXKGnpaKlHYQ7bNLW5hsyj3UsryDhKQ2MYMWgvY3+zNJQfDHbOZ2xSY +/4SRfKp7rrX/1p4swk6E18rovMW+mrud/bZrO7qTv96BqHlCEfJbvYbwDMgYpbl6VKa eRMxDCa68i5/3bNzOV3oFnle08Aanoi/jmoCjsbuyOf6wqRZGRnoDFR0ebssKLNA5223 Heow== X-Gm-Message-State: AOAM530iTKql0UCOihcXqgDAfGUNJib60wpMK4TRsJtjGF3dpMbm6RY2 wvyIZbG3Fxh7pSz/bbr2pprezVspfu1b1Nq8qbApPg== X-Google-Smtp-Source: ABdhPJxklFVbfFNwNwAAaKz6vbxUZ69o/Z0+23/AeFD9ENbDqkgki+Ljib01MLFfq9nwJFRwK6T2DanfvfvyeHNfctY= X-Received: by 2002:a05:6402:19a:: with SMTP id r26mr3358969edv.44.1615287704169; Tue, 09 Mar 2021 03:01:44 -0800 (PST) MIME-Version: 1.0 References: <20210301142315.30920-1-steven.price@arm.com> <20210301142315.30920-7-steven.price@arm.com> In-Reply-To: <20210301142315.30920-7-steven.price@arm.com> From: Peter Maydell Date: Tue, 9 Mar 2021 11:01:27 +0000 Message-ID: Subject: Re: [PATCH v9 6/6] KVM: arm64: Document MTE capability and ioctl To: Steven Price Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=peter.maydell@linaro.org; helo=mail-ed1-x532.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , QEMU Developers , Catalin Marinas , Juan Quintela , Richard Henderson , lkml - Kernel Mailing List , Dave Martin , James Morse , arm-mail-list , Marc Zyngier , Thomas Gleixner , Will Deacon , kvmarm , Julien Thierry Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, 1 Mar 2021 at 14:23, 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. > > Signed-off-by: Steven Price > --- > Documentation/virt/kvm/api.rst | 37 ++++++++++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index aed52b0fc16e..1406ea138127 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -4939,6 +4939,23 @@ KVM_XEN_VCPU_ATTR_TYPE_VCPU_TIME_INFO > Allows Xen vCPU attributes to be read. For the structure and types, > see KVM_XEN_VCPU_SET_ATTR above. > > +4.131 KVM_ARM_MTE_COPY_TAGS > +--------------------------- > + > +:Capability: KVM_CAP_ARM_MTE > +:Architectures: arm64 > +:Type: vm ioctl > +:Parameters: struct kvm_arm_copy_mte_tags > +:Returns: 0 on success, < 0 on error > + > +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. Mostly virt/kvm/api.rst seems to include documentation of the associated structs, something like: :: struct kvm_arm_copy_mte_tags { __u64 guest_ipa; __u64 length; union { void __user *addr; __u64 padding; }; __u64 flags; }; which saves the reader having to cross-reference against the header file. It also means you can more naturally use the actual field names in the doc, eg: > +The > +starting address and length of guest memory must be ``PAGE_SIZE`` aligned. you could say "The guest_ipa and length fields" here. Also "The addr field must point to a buffer which the tags will be copied to or from." I assume. > +The size of the buffer to store the tags is ``(length / MTE_GRANULE_SIZE)`` > +bytes (i.e. 1/16th of the corresponding size). > + Each byte contains a single tag > +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and > +``PTRACE_POKEMTETAGS``. What are the valid values for 'flags' ? It looks like they specify which direction the copy is, which we definitely need to document here. What happens if the caller requests a tag copy for an area of guest address space which doesn't have tags (eg it has nothing mapped), or for an area of guest addres space which has tags in some parts but not in others ? > + > 5. The kvm_run structure > ======================== > > @@ -6227,6 +6244,25 @@ KVM_RUN_BUS_LOCK flag is used to distinguish between them. > This capability can be used to check / enable 2nd DAWR feature provided > by POWER10 processor. > > +7.23 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 the guest will be granted access. > + > +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 s/,/;/ > +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 "guest." > + > 8. Other capabilities. > ====================== > > @@ -6716,3 +6752,4 @@ KVM_XEN_HVM_SET_ATTR, KVM_XEN_HVM_GET_ATTR, KVM_XEN_VCPU_SET_ATTR and > KVM_XEN_VCPU_GET_ATTR ioctls, as well as the delivery of exception vectors > for event channel upcalls when the evtchn_upcall_pending field of a vcpu's > vcpu_info is set. > + > -- > 2.20.1 Stray whitespace change ? thanks -- PMM 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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 D56D5C433E0 for ; Tue, 9 Mar 2021 11:01:55 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 43EC36523B for ; Tue, 9 Mar 2021 11:01:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 43EC36523B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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 B9DEA4B3C7; Tue, 9 Mar 2021 06:01:54 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@linaro.org 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-vwSiQgoAK0; Tue, 9 Mar 2021 06:01:49 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id AEC0B4B3E2; Tue, 9 Mar 2021 06:01:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 44CB14B413 for ; Tue, 9 Mar 2021 06:01:49 -0500 (EST) 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 9rno5qIwe8io for ; Tue, 9 Mar 2021 06:01:45 -0500 (EST) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 451214B407 for ; Tue, 9 Mar 2021 06:01:45 -0500 (EST) Received: by mail-ed1-f41.google.com with SMTP id bd6so19177443edb.10 for ; Tue, 09 Mar 2021 03:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vdZ4o+zoeGhBm3eWUzEKAm3SjsyvDpQ7XHjJEgZbpvA=; b=mLLgcOkGiUnzFw3UE3oQBVac/QperD9HatYPiTHaHcjhWXjSDD9xGqDW9WAKvrfswy 12Kaqb8Mxo0fSaxpDqm5TJki2Vs+jTW3433sX1ZHcUJ2m4/Pi8FnaoAW78pwEm2X2erO 8fRS7lCr/tep5XCTaV5V8csBu2hfOkYN7lB7rNFPcE42icw/QkJvQMHzxIFuBAyUjAKG INrt/uotzmU+770iB07TJu/T//V7mQ1Qt4g/7OPcU5T2DXTKnmMfH8FkMRcC01sKh52i FJwt39CTqR9mmdQ4vly4YFUdfl8mt8Hy/tDK5ys81SjtV9JAkLVYUbJnVwi+M/VNYQMN 5TUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vdZ4o+zoeGhBm3eWUzEKAm3SjsyvDpQ7XHjJEgZbpvA=; b=Pf2tM8H0ZpWFPxV1RlSaGR9FLfnG8Duvx2p+UklLyGG/DXRW2Ku9b/bpFAEoDOSVp6 sMvpRHitBu8UTWkvDWxzjYzBud16pzlpJNtBm2qO2P9Q+qlw6s+/YqKaPfrz4YLOrU6q MHkutn2UcNOepXoqeOsx7FWjb6hYVDd9EVr02KbJkDSAM4ZReb9A+yrlug4DeulrmJMB egUaVBQEgG/CPQ5wwhuv0UFCxt7WFPrQLpNVXsw91DAAVKnsUeyr3s1daWmZQdku7m4u IJjWf9xV5m1bay+2ucjv4zACRaYlJQWC9wogQ8i0KY/VFwe2e41wUSHFsd95QlKFb4Rm 3dzQ== X-Gm-Message-State: AOAM5323wukdi0hrt0BILReOmk+64nCTRI9LYgmYxYZKup1lApxo672l GdCwtlBWHnsUJz9YjQQYpw1EoXEHmi2AeAHn+hEWCg== X-Google-Smtp-Source: ABdhPJxklFVbfFNwNwAAaKz6vbxUZ69o/Z0+23/AeFD9ENbDqkgki+Ljib01MLFfq9nwJFRwK6T2DanfvfvyeHNfctY= X-Received: by 2002:a05:6402:19a:: with SMTP id r26mr3358969edv.44.1615287704169; Tue, 09 Mar 2021 03:01:44 -0800 (PST) MIME-Version: 1.0 References: <20210301142315.30920-1-steven.price@arm.com> <20210301142315.30920-7-steven.price@arm.com> In-Reply-To: <20210301142315.30920-7-steven.price@arm.com> From: Peter Maydell Date: Tue, 9 Mar 2021 11:01:27 +0000 Message-ID: Subject: Re: [PATCH v9 6/6] KVM: arm64: Document MTE capability and ioctl To: Steven Price Cc: "Dr. David Alan Gilbert" , QEMU Developers , Catalin Marinas , Juan Quintela , Richard Henderson , lkml - Kernel Mailing List , Dave Martin , arm-mail-list , Marc Zyngier , Thomas Gleixner , Will Deacon , kvmarm 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, 1 Mar 2021 at 14:23, 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. > > Signed-off-by: Steven Price > --- > Documentation/virt/kvm/api.rst | 37 ++++++++++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index aed52b0fc16e..1406ea138127 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -4939,6 +4939,23 @@ KVM_XEN_VCPU_ATTR_TYPE_VCPU_TIME_INFO > Allows Xen vCPU attributes to be read. For the structure and types, > see KVM_XEN_VCPU_SET_ATTR above. > > +4.131 KVM_ARM_MTE_COPY_TAGS > +--------------------------- > + > +:Capability: KVM_CAP_ARM_MTE > +:Architectures: arm64 > +:Type: vm ioctl > +:Parameters: struct kvm_arm_copy_mte_tags > +:Returns: 0 on success, < 0 on error > + > +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. Mostly virt/kvm/api.rst seems to include documentation of the associated structs, something like: :: struct kvm_arm_copy_mte_tags { __u64 guest_ipa; __u64 length; union { void __user *addr; __u64 padding; }; __u64 flags; }; which saves the reader having to cross-reference against the header file. It also means you can more naturally use the actual field names in the doc, eg: > +The > +starting address and length of guest memory must be ``PAGE_SIZE`` aligned. you could say "The guest_ipa and length fields" here. Also "The addr field must point to a buffer which the tags will be copied to or from." I assume. > +The size of the buffer to store the tags is ``(length / MTE_GRANULE_SIZE)`` > +bytes (i.e. 1/16th of the corresponding size). > + Each byte contains a single tag > +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and > +``PTRACE_POKEMTETAGS``. What are the valid values for 'flags' ? It looks like they specify which direction the copy is, which we definitely need to document here. What happens if the caller requests a tag copy for an area of guest address space which doesn't have tags (eg it has nothing mapped), or for an area of guest addres space which has tags in some parts but not in others ? > + > 5. The kvm_run structure > ======================== > > @@ -6227,6 +6244,25 @@ KVM_RUN_BUS_LOCK flag is used to distinguish between them. > This capability can be used to check / enable 2nd DAWR feature provided > by POWER10 processor. > > +7.23 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 the guest will be granted access. > + > +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 s/,/;/ > +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 "guest." > + > 8. Other capabilities. > ====================== > > @@ -6716,3 +6752,4 @@ KVM_XEN_HVM_SET_ATTR, KVM_XEN_HVM_GET_ATTR, KVM_XEN_VCPU_SET_ATTR and > KVM_XEN_VCPU_GET_ATTR ioctls, as well as the delivery of exception vectors > for event channel upcalls when the evtchn_upcall_pending field of a vcpu's > vcpu_info is set. > + > -- > 2.20.1 Stray whitespace change ? thanks -- PMM _______________________________________________ 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.0 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 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 42200C433E0 for ; Tue, 9 Mar 2021 11:03:49 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 BCB2D6524C for ; Tue, 9 Mar 2021 11:03:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BCB2D6524C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=em+BigwvsteDDVWUJ5Ea/3Xka2ya7IOYDwdhX15nW+E=; b=eTrpwTcIpIT20a5+B5+dnhiGt 7XN2oamLkQOyUsFJTGtHEIuvECeJs3XjGo+1ZQsk0FZGLYSFVWYCDBPT9TL+gr4OaYggGjTOCjMdR 8qollEhajxxlNvCOj/bkATC6hUApGD6DspspFaIy6TdQICsj7rQnQN3UDk/Wp5V02wbzu0Ih7UX6H 8ujZrabU+dgL8xZJtdqS9B/SvBM0TjGJcPWwiv1BgrbimlQ/m4ufYh9VOkTCWrYYSU81RfITNz9Wx asVHMGHjg2XQ3z+usLsqBWk/OoHkOALPgbb1sLfSgFEX8v2bXCYKN4QEZwMXNXMojIBcGl0Sk8H1l YbXaUGV4w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lJa7b-004Fda-GB; Tue, 09 Mar 2021 11:01:51 +0000 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lJa7V-004FdD-Hj for linux-arm-kernel@lists.infradead.org; Tue, 09 Mar 2021 11:01:47 +0000 Received: by mail-ed1-x529.google.com with SMTP id l12so19268120edt.3 for ; Tue, 09 Mar 2021 03:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vdZ4o+zoeGhBm3eWUzEKAm3SjsyvDpQ7XHjJEgZbpvA=; b=mLLgcOkGiUnzFw3UE3oQBVac/QperD9HatYPiTHaHcjhWXjSDD9xGqDW9WAKvrfswy 12Kaqb8Mxo0fSaxpDqm5TJki2Vs+jTW3433sX1ZHcUJ2m4/Pi8FnaoAW78pwEm2X2erO 8fRS7lCr/tep5XCTaV5V8csBu2hfOkYN7lB7rNFPcE42icw/QkJvQMHzxIFuBAyUjAKG INrt/uotzmU+770iB07TJu/T//V7mQ1Qt4g/7OPcU5T2DXTKnmMfH8FkMRcC01sKh52i FJwt39CTqR9mmdQ4vly4YFUdfl8mt8Hy/tDK5ys81SjtV9JAkLVYUbJnVwi+M/VNYQMN 5TUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vdZ4o+zoeGhBm3eWUzEKAm3SjsyvDpQ7XHjJEgZbpvA=; b=igcgYOM6+5ykkC0tZ021+VXX0/319CvJvuGbCUAR6l2gkGloJVd54DdFDEQ2PkdxUF EhXciz+sM4mXfrA0qZPA5nIg4r3p5u16i4uy2ryiDT22na5VKt794190iUrVL/SQFJvr i3P3wkF0bPWLN24NEoU0oK2k31a8jyWwFit4jxJUdv4LNNI9wFk6c6BoP3QF4q1oSk55 S4nhIPaVO9UiZIu0Sz2VmKuA9oRuf13qe+vG+Uji0XEpL/+EYHbfV4N21Nc1dRovY81+ zx1Ru1qRdIWxKZi2h3lkSOa1GQyr3yQnFRiFMUiiu2HtYUvWF+FZklubTbtmgFeSt+F/ 7DmQ== X-Gm-Message-State: AOAM530FkU4cziXTR1QHhkRHP9Jbs7mLVlJBFkespRyMBHfVEd8SBrmQ 6TJ/V1DZMEBP1Joaw9YyILlthqeN9k49bfllOlwSbQ== X-Google-Smtp-Source: ABdhPJxklFVbfFNwNwAAaKz6vbxUZ69o/Z0+23/AeFD9ENbDqkgki+Ljib01MLFfq9nwJFRwK6T2DanfvfvyeHNfctY= X-Received: by 2002:a05:6402:19a:: with SMTP id r26mr3358969edv.44.1615287704169; Tue, 09 Mar 2021 03:01:44 -0800 (PST) MIME-Version: 1.0 References: <20210301142315.30920-1-steven.price@arm.com> <20210301142315.30920-7-steven.price@arm.com> In-Reply-To: <20210301142315.30920-7-steven.price@arm.com> From: Peter Maydell Date: Tue, 9 Mar 2021 11:01:27 +0000 Message-ID: Subject: Re: [PATCH v9 6/6] KVM: arm64: Document MTE capability and ioctl To: Steven Price Cc: Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm , arm-mail-list , lkml - Kernel Mailing List , Dave Martin , Mark Rutland , Thomas Gleixner , QEMU Developers , Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Haibo Xu , Andrew Jones X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210309_110145_873294_FBCFCFA3 X-CRM114-Status: GOOD ( 28.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, 1 Mar 2021 at 14:23, 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. > > Signed-off-by: Steven Price > --- > Documentation/virt/kvm/api.rst | 37 ++++++++++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index aed52b0fc16e..1406ea138127 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -4939,6 +4939,23 @@ KVM_XEN_VCPU_ATTR_TYPE_VCPU_TIME_INFO > Allows Xen vCPU attributes to be read. For the structure and types, > see KVM_XEN_VCPU_SET_ATTR above. > > +4.131 KVM_ARM_MTE_COPY_TAGS > +--------------------------- > + > +:Capability: KVM_CAP_ARM_MTE > +:Architectures: arm64 > +:Type: vm ioctl > +:Parameters: struct kvm_arm_copy_mte_tags > +:Returns: 0 on success, < 0 on error > + > +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. Mostly virt/kvm/api.rst seems to include documentation of the associated structs, something like: :: struct kvm_arm_copy_mte_tags { __u64 guest_ipa; __u64 length; union { void __user *addr; __u64 padding; }; __u64 flags; }; which saves the reader having to cross-reference against the header file. It also means you can more naturally use the actual field names in the doc, eg: > +The > +starting address and length of guest memory must be ``PAGE_SIZE`` aligned. you could say "The guest_ipa and length fields" here. Also "The addr field must point to a buffer which the tags will be copied to or from." I assume. > +The size of the buffer to store the tags is ``(length / MTE_GRANULE_SIZE)`` > +bytes (i.e. 1/16th of the corresponding size). > + Each byte contains a single tag > +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and > +``PTRACE_POKEMTETAGS``. What are the valid values for 'flags' ? It looks like they specify which direction the copy is, which we definitely need to document here. What happens if the caller requests a tag copy for an area of guest address space which doesn't have tags (eg it has nothing mapped), or for an area of guest addres space which has tags in some parts but not in others ? > + > 5. The kvm_run structure > ======================== > > @@ -6227,6 +6244,25 @@ KVM_RUN_BUS_LOCK flag is used to distinguish between them. > This capability can be used to check / enable 2nd DAWR feature provided > by POWER10 processor. > > +7.23 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 the guest will be granted access. > + > +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 s/,/;/ > +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 "guest." > + > 8. Other capabilities. > ====================== > > @@ -6716,3 +6752,4 @@ KVM_XEN_HVM_SET_ATTR, KVM_XEN_HVM_GET_ATTR, KVM_XEN_VCPU_SET_ATTR and > KVM_XEN_VCPU_GET_ATTR ioctls, as well as the delivery of exception vectors > for event channel upcalls when the evtchn_upcall_pending field of a vcpu's > vcpu_info is set. > + > -- > 2.20.1 Stray whitespace change ? thanks -- PMM _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel