From patchwork Thu Feb 8 15:18:30 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shameerali Kolothum Thodi X-Patchwork-Id: 13549960 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4E8C8C4828F for ; Thu, 8 Feb 2024 15:21:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:CC :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=8mgRBbzh8tRfayUBor+CLJV6YmVFU8ZeueHyoeTOO/U=; b=tfdJJaxm20v7Vo OR+gjoNW1arD78f6gDkYAQFYwmHI54UnlLu6y0ErT9QjrI411/yQ7G3osDXRiniv57pkWj2e0dkSG bS5RBZvB+xitbBNxKawJvoELedRBDcFmH/nfc0fK9n7x7o8kYk1dyYFx7448rBuJ40CdH3Q6QUkwp yw1FB5YSRJ//yyvmyLmsfBYbWoZUzG+hXLmQQqwuz+FJnv3SAAFwy5sF+kwPz5DmLFy1P/XFM319b HbejiGsU55TiorgulTt0TFwsGQjPxlWIotSm2cqcAb0QJ6LcvW0bHJcngAdUDFA/cwbwjer2Irxxb oWeiyff74duGQy87xmHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rY6Cv-0000000E9HS-2BML; Thu, 08 Feb 2024 15:20:57 +0000 Received: from frasgout.his.huawei.com ([185.176.79.56]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rY6Cr-0000000E9Dh-2n9B for linux-arm-kernel@lists.infradead.org; Thu, 08 Feb 2024 15:20:55 +0000 Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TW0vy00GNz67nmT; Thu, 8 Feb 2024 23:17:17 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id E33C9140595; Thu, 8 Feb 2024 23:20:39 +0800 (CST) Received: from A2303104131.china.huawei.com (10.202.227.28) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 8 Feb 2024 15:20:33 +0000 From: Shameer Kolothum To: , , , CC: , , , , , , , , Subject: [RFC PATCH v2 0/7] iommu/arm-smmu-v3: Use pinned KVM VMID for stage 2 Date: Thu, 8 Feb 2024 15:18:30 +0000 Message-ID: <20240208151837.35068-1-shameerali.kolothum.thodi@huawei.com> X-Mailer: git-send-email 2.12.0.windows.1 MIME-Version: 1.0 X-Originating-IP: [10.202.227.28] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240208_072054_017970_36E1CF75 X-CRM114-Status: GOOD ( 11.02 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On an ARM64 system with a SMMUv3 implementation that fully supports Broadcast TLB Maintenance(BTM) feature as part of the Distributed Virtual Memory(DVM) protocol, the CPU TLB invalidate instructions are received by SMMUv3. This is very useful when the SMMUv3 shares the page tables with the CPU(eg: Guest SVA use case). For this to work, the SMMUv3 must use the same VMID that is allocated by KVM to configure the nested stage 2(S2) translations. An earlier proposal sent out[1] a while back resulted in changing the ARM64/KVM VMID allocator similar to the ASID allocator to make it better suited for this. This RFC adds, -Support for pinned KVM VMID. -Support associating KVM pointer and iommufd ctx. -Changes to domain_alloc_user() to receive a kvm pointer. -Configure SMMUV3 S2 using KVM VMID -Finally enable BTM only if SMMUV3 supports S1 translation. This is to make sure that PAGING domains always use S1 and S2 is only used for nested domains with a valid KVM. The idea is to make sure when BTM is enabled in Guest, we use KVM VMID for S2. Not sure I miss any explicit TLB invalidations with any use case that may configure a S2 with a private VMID that matches a KVM one. This is based on Jason's ongoing SMMUv3 refactor series[2]. Please take a look and let me know. Thanks, Shameer 1. https://lore.kernel.org/linux-arm-kernel/20210222155338.26132-1-shameerali.kolothum.thodi@huawei.com/ 2. https://lore.kernel.org/linux-arm-kernel/0-v5-cd1be8dd9c71+3fa-smmuv3_newapi_p1_jgg@nvidia.com/ Jean-Philippe Brucker (1): iommu/arm-smmu-v3: Enable broadcast TLB maintenance Shameer Kolothum (6): KVM: Add generic infrastructure to support pinned VMIDs KVM: arm64: Introduce support to pin VMIDs KVM: arm64: Add interfaces for pinned VMID support iommufd: Associate kvm pointer to iommufd ctx iommu: Pass in kvm pointer to domain_alloc_user iommu/arm-smmu-v3: Use KVM VMID for s2 stage arch/arm64/include/asm/kvm_host.h | 3 + arch/arm64/kvm/Kconfig | 1 + arch/arm64/kvm/arm.c | 14 ++++ arch/arm64/kvm/vmid.c | 84 ++++++++++++++++++++- drivers/iommu/amd/iommu.c | 1 + drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 42 +++++++++-- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 3 + drivers/iommu/intel/iommu.c | 1 + drivers/iommu/iommufd/hw_pagetable.c | 5 +- drivers/iommu/iommufd/iommufd_private.h | 3 + drivers/iommu/iommufd/main.c | 14 ++++ drivers/iommu/iommufd/selftest.c | 1 + drivers/vfio/device_cdev.c | 3 + include/linux/iommu.h | 3 +- include/linux/iommufd.h | 7 ++ include/linux/kvm_host.h | 18 +++++ virt/kvm/Kconfig | 3 + virt/kvm/kvm_main.c | 23 ++++++ 18 files changed, 218 insertions(+), 11 deletions(-)