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 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 3BA34C4167B for ; Mon, 27 Nov 2023 16:11:29 +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:In-Reply-To:References: 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: List-Owner; bh=t263LMFuCziTalB7CKuXcfYUIadlnhzxnn7Zy8TVfAY=; b=WEZIVGNbYBMmdF oZDYI1n2d/EEfZ6PBvC/tqz3Zn/Fdy+qT6pAWT/ubKknL11vgqcLFg0eulpENd21f5Nqr+IrgIr4U c2CXQ8GeDKDdkmG4ZYmCiq1ybXt1W2EJfL6fTIELsW0R6vPA94Fi5LAAwQ6Ehpynkg3ONMBHkfAYm sW9FbeawBL4tF9CLE5qHOfSTaL5g8E1oMvF/vmvI/EDxJEpp+YgBo79+FXfrSGV2ILaUO2D+KggT5 ltjBoo1oTNSoxyP8yVhUtkQVFUvqgyaf+HXVpc9Jfcs/yCuQksntwVVYVdF0yxJXEaSwMyftMtvGS qzXJibKq3jUdaF5ILHTA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r7eCD-002v8d-2R; Mon, 27 Nov 2023 16:10:53 +0000 Received: from frasgout.his.huawei.com ([185.176.79.56]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r7eC8-002v66-2n for linux-arm-kernel@lists.infradead.org; Mon, 27 Nov 2023 16:10:51 +0000 Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Sf9Xq3Fmfz6JBR6; Tue, 28 Nov 2023 00:10:19 +0800 (CST) Received: from lhrpeml500001.china.huawei.com (unknown [7.191.163.213]) by mail.maildlp.com (Postfix) with ESMTPS id B49E9140C98; Tue, 28 Nov 2023 00:10:33 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (7.191.163.240) by lhrpeml500001.china.huawei.com (7.191.163.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 27 Nov 2023 16:10:33 +0000 Received: from lhrpeml500005.china.huawei.com ([7.191.163.240]) by lhrpeml500005.china.huawei.com ([7.191.163.240]) with mapi id 15.01.2507.035; Mon, 27 Nov 2023 16:10:33 +0000 From: Shameerali Kolothum Thodi To: Jason Gunthorpe , "iommu@lists.linux.dev" , Joerg Roedel , "linux-arm-kernel@lists.infradead.org" , Robin Murphy , Will Deacon CC: Michael Shavit , Nicolin Chen Subject: RE: [PATCH v2 00/19] Update SMMUv3 to the modern iommu API (part 1/3) Thread-Topic: [PATCH v2 00/19] Update SMMUv3 to the modern iommu API (part 1/3) Thread-Index: AQHaFlpcboVCOVh91k2mJ0kS0C1kaLCOZrqw Date: Mon, 27 Nov 2023 16:10:33 +0000 Message-ID: References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com> In-Reply-To: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.227.178] MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231127_081049_207721_1579498E X-CRM114-Status: GOOD ( 25.39 ) 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 > -----Original Message----- > From: Jason Gunthorpe [mailto:jgg@nvidia.com] > Sent: 13 November 2023 17:53 > To: iommu@lists.linux.dev; Joerg Roedel ; > linux-arm-kernel@lists.infradead.org; Robin Murphy > ; Will Deacon > Cc: Michael Shavit ; Nicolin Chen > ; Shameerali Kolothum Thodi > > Subject: [PATCH v2 00/19] Update SMMUv3 to the modern iommu API (part > 1/3) > > The SMMUv3 driver was originally written in 2015 when the iommu driver > facing API looked quite different. The API has evolved, especially lately, > and the driver has fallen behind. > > This work aims to bring make the SMMUv3 driver the best IOMMU driver > with > the most comprehensive implementation of the API. After all parts it > addresses: > > - Global static BLOCKED and IDENTITY domains with 'never fail' attach > semantics. BLOCKED is desired for efficient VFIO. > > - Support map before attach for PAGING iommu_domains. > > - attach_dev failure does not change the HW configuration. > > - Fully hitless transitions between IDENTITY -> DMA -> IDENTITY. > The API has IOMMU_RESV_DIRECT which is expected to be > continuously translating. > > - Safe transitions between PAGING -> BLOCKED, do not ever temporarily > do IDENTITY. This is required for iommufd security. > > - Full PASID API support including: > - S1/SVA domains attached to PASIDs > - IDENTITY/BLOCKED/S1 attached to RID > - Change of the RID domain while PASIDs are attached > > - Streamlined SVA support using the core infrastructure > > - Hitless, whenever possible, change between two domains > > - iommufd IOMMU_GET_HW_INFO, IOMMU_HWPT_ALLOC_NEST_PARENT, > and > IOMMU_DOMAIN_NESTED support > > Over all these things are going to become more accessible to iommufd, and > exposed to VMs, so it is important for the driver to have a robust > implementation of the API. > > The work is split into three parts, with this part largely focusing on the > STE and building up to the BLOCKED & IDENTITY global static domains. > > The second part largely focuses on the CD and builds up to having a common > PASID infrastructure that SVA and S1 domains equally use. > > The third part has some random cleanups and the iommufd related parts. > > Overall this takes the approach of turning the STE/CD programming upside > down where the CD/STE value is computed right at a driver callback > function and then pushed down into programming logic. The programming > logic hides the details of the required CD/STE tear-less update. This > makes the CD/STE functions independent of the arm_smmu_domain which > makes > it fairly straightforward to untangle all the different call chains, and > add news ones. > > Further, this frees the arm_smmu_domain related logic from keeping track > of what state the STE/CD is currently in so it can carefully sequence the > correct update. There are many new update pairs that are subtly introduced > as the work progresses. > > The locking to support BTM via arm_smmu_asid_lock is a bit subtle right > now and patches throughout this work adjust and tighten this so that it is > clearer and doesn't get broken. > > Once the lower STE layers no longer need to touch arm_smmu_domain we > can > isolate struct arm_smmu_domain to be only used for PAGING domains, audit > all the to_smmu_domain() calls to be only in PAGING domain ops, and > introduce the normal global static BLOCKED/IDENTITY domains using the > new > STE infrastructure. Part 2 will ultimately migrate SVA over to use > arm_smmu_domain as well. > > All parts are on github: > > https://github.com/jgunthorpe/linux/commits/smmuv3_newapi Hi Jason, I had a go with the above branch on our HiSilicon D06 board(SMMUv3). Basically covered the following functionality test runs: -Host kernel: boot with DOMAIN_DMA. -Host kernel: boot with DOMAIN_IDENTITY. -Host kernel: ACC dev SVA test run with uadk/uadk_tool benchmark. And with Qemu branch: https://github.com/yiliu1765/qemu/tree/zhenzhong/iommufd_cdev_v7 -Guest boot with a n/w VF dev assigned, legacy VFIO mode. -Guest boot with a n/w VF dev assigned, IOMMUFD mode. -Device Hot plug(add/del) on both VFIO and IOMMUFD modes. All the tests seems to be fine so far. FWIW: Tested-by: Shameer Kolothum Thanks, Shameer _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel