From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E52771A38F6 for ; Sat, 23 Mar 2024 13:38:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711201092; cv=none; b=LoETWpmWDdAfKc7WyF1nAJqSBMY0DQ/EYfBYccVuliEXrTISdllqa5VpBKRtwTA0g3jKMHljmqYiC9rJj1LO2Ufel+PFXgl8I+pjLDQFa+bMqM9YX3MJeEjx731Nhto0EsxxjJiUstj1/TktHuwqs5hZwNJazHRj3sBlheqCIY0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711201092; c=relaxed/simple; bh=Jzbk+C2s5wxMp72wmVe/UdYj7O3NNOwtIgGdoLPoaT8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PUMbEi4fpWBHGPfwcZfrpz8IvWBd3Y0viX7IpK+hd8B21pABZAiWyoWrzLvGSeNHxXGqyDIWZJoJWStIswDvERw3fElRc90I1bNBS0ypzkqT4nLSXvAikSWik2nZvDPHJcAcyiC5XrrWdnS9n8kABZJWOdBVJr4rsrNlL/w6naY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ZNixfBO+; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZNixfBO+" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4140eed8a4fso31815e9.0 for ; Sat, 23 Mar 2024 06:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1711201089; x=1711805889; darn=lists.linux.dev; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=X2lObstm1ERvlU1Nkp+L7+Kxf3ZnfKU4Wltlmi3CA3w=; b=ZNixfBO+LRE4sV7miHZZoKvPk+tFzlQaNRbALLEvOWY3i+Wmy/vOJu+Bex+9DLlcYk F4gCY9Ly8xtPdZ906LTzMnd3vMMJ4FVHUnw31R9HK6gu02UGX3jELHypu6zzAO2Uxp/E caW9REdoDKAYw1dkC22Sp4b9ZDt0xVSFCygwwv4WV9LefPsrGd09DNfrq2HZeYdgh9sF 3DFoeiIVrJz4LXZgt4huQeVsBOXNgbVKmEAKZ7QYy9iRNZuvoRMALUH7esmJywEugruW vJJQ/Xj2QgpuUuD1F+74eFzhvpf6LlQ6pJ8M9mNuTvv6niQKUT3Jf1Yj04W9MKb0KMnZ x6SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711201089; x=1711805889; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=X2lObstm1ERvlU1Nkp+L7+Kxf3ZnfKU4Wltlmi3CA3w=; b=xB+VUUco7CMDn61Y6/IMK70yLt4LzX6KLAtALMUjBETrbU915hKk50PzCw4+GeIMK1 WS4EKu78f9Wp+E4PHP/Mdun3XlAzdVIz4zw0/cJo37i0+lf+w6DrGrUfsi4IXEg2rm52 Lty3ZDSwBqsyJzrmVLa+WJ9UPgzZILohsddsYL6U65IFO8wRslBTd5LCwZi6/gcPKZNM M3lcUgBnj3QH2W5Xh/5sERQE9t0Q+S7FB1xT3/cH5cYK8085wAvDx23VnPQyPKHvPvIv Y0XjoKgMkrLaavQgT8/l5vL7+Yr3Y9STOfJusqPHc78EyMnX+msE+/yjJ39Q8qQO2C2N /GVA== X-Gm-Message-State: AOJu0Yybb4tP/o/MH+8Q0//kIHlX42RXWrcqy/FZ7zCsBdeFqEYNx6ZM F4QvSZFyEF4whOD5Jha+t8s6BjWjzJlx/tjPTEMp9gJ6g9mBWRZs88p5Z296HQ== X-Google-Smtp-Source: AGHT+IH0YEkJX+tjrjcL88W6+N0EJawA09q6e87WEWXzxMNv3w8fp9nad4+db5XgANVhctp+gnzw1g== X-Received: by 2002:a05:600c:4856:b0:414:1400:a776 with SMTP id j22-20020a05600c485600b004141400a776mr641509wmo.5.1711201089204; Sat, 23 Mar 2024 06:38:09 -0700 (PDT) Received: from google.com (180.232.140.34.bc.googleusercontent.com. [34.140.232.180]) by smtp.gmail.com with ESMTPSA id n14-20020a5d51ce000000b0033e9fca1e49sm4446933wrv.60.2024.03.23.06.38.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Mar 2024 06:38:08 -0700 (PDT) Date: Sat, 23 Mar 2024 13:38:04 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: iommu@lists.linux.dev, Joerg Roedel , linux-arm-kernel@lists.infradead.org, Robin Murphy , Will Deacon , Eric Auger , Jean-Philippe Brucker , Moritz Fischer , Michael Shavit , Nicolin Chen , patches@lists.linux.dev, Shameerali Kolothum Thodi Subject: Re: [PATCH v5 00/27] Update SMMUv3 to the modern iommu API (part 2/3) Message-ID: References: <0-v5-9a37e0c884ce+31e3-smmuv3_newapi_p2_jgg@nvidia.com> Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0-v5-9a37e0c884ce+31e3-smmuv3_newapi_p2_jgg@nvidia.com> Hi Jason, On Mon, Mar 04, 2024 at 07:43:48PM -0400, Jason Gunthorpe wrote: > Continuing the work of part 1 this focuses on the CD, PASID and SVA > components: > > - attach_dev failure does not change the HW configuration. > > - Full PASID API support including: > - S1/SVA domains attached to PASIDs I am still going through the series, but I see at the end the main SMMUv3 driver has set_dev_pasid operation, are there any in-tree drivers that use that? (and how can I test it). > - 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 Can you please clarify what cases are expected to be hitless? >From what I see if ASID and TTB0 changes that would break the CD. > > Making the CD programming work like the new STE programming allows > untangling some of the confusing SVA flows. From there the focus is on > building out the core infrastructure for dealing with PASID and CD > entries, then keeping track of unique SSID's for ATS invalidation. > > The ATS ordering is generalized so that the PASID flow can use it and put > into a form where it is fully hitless, whenever possible. Care is taken to > ensure that ATC flushes are present after any change in translation. > > Finally we simply kill the entire outdated SVA mmu_notifier implementation > in one shot and switch it over to the newly created generic PASID & CD > code. This avoids the messy and confusing approach of trying to > incrementally untangle this in place. The new code is small and simple > enough this is much better than trying to figure out smaller steps. > > Once SVA is resting on the right CD code it is straightforward to make the > PASID interface functionally complete. > > It achieves the same goals as the several series from Michael and the S1DSS > series from Nicolin that were trying to improve portions of the API. > > This is on github: > https://github.com/jgunthorpe/linux/commits/smmuv3_newapi > > v5: > - Rebase on v6.8-rc7 & Will's tree > - Accomdate the SVA rc patch removing the master list iteration > - Move the kfree(to_smmu_domain(domain)) hunk to the right patch > - Move S1DSS get_used hunk to "Allow IDENTITY/BLOCKED to be set while > PASID is used" > v4: https://lore.kernel.org/r/0-v4-e7091cdd9e8d+43b1-smmuv3_newapi_p2_jgg@nvidia.com > - Rebase on v6.8-rc1, adjust to use mm_get_enqcmd_pasid() and eventually > remove all references from ARM. Move the new ARM_SMMU_FEAT_STALL_FORCE > stuff to arm_smmu_make_sva_cd() > - Adjust to use the new shared STE/CD writer logic. Disable some of the > sanity checks for the interior of the series > - Return ERR_PTR from domain_alloc functions > - Move the ATS disablement flow into arm_smmu_attach_prepare()/commit() > which lets all the STE update flows use the same sequence. This is > needed for nesting in part 3 > - Put ssid in attach_state > - Replace to_smmu_domain_safe() with to_smmu_domain_devices() > v3: https://lore.kernel.org/r/0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com > - Rebase on the latest part 1 > - update comments and commit messages > - Fix error exit in arm_smmu_set_pasid() > - Fix inverted logic for btm_invalidation > - Add missing ATC invalidation on mm release > - Add a big comment explaining that BTM is not enabled and what is > missing to enable it. > v2: https://lore.kernel.org/r/0-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com > - Rebased on iommmufd + Joerg's tree > - Use sid_smmu_domain consistently to refer to the domain attached to the > device (eg the PCIe RID) > - Rework how arm_smmu_attach_*() and callers flow to be more careful > about ordering around ATC invalidation. The ATC must be invalidated > after it is impossible to establish stale entires. > - ATS disable is now entirely part of arm_smmu_attach_dev_ste(), which is > the only STE type that ever disables ATS. > - Remove the 'existing_master_domain' optimization, the code is > functionally fine without it. > - Whitespace, spelling, and checkpatch related items > - Fixed wrong value stored in the xa for the BTM flows > - Use pasid more consistently instead of id > v1: https://lore.kernel.org/r/0-v1-afbb86647bbd+5-smmuv3_newapi_p2_jgg@nvidia.com > > Jason Gunthorpe (27): > iommu/arm-smmu-v3: Do not allow a SVA domain to be set on the wrong > PASID > iommu/arm-smmu-v3: Do not ATC invalidate the entire domain > iommu/arm-smmu-v3: Add a type for the CD entry > iommu/arm-smmu-v3: Add an ops indirection to the STE code > iommu/arm-smmu-v3: Make CD programming use arm_smmu_write_entry() > iommu/arm-smmu-v3: Consolidate clearing a CD table entry > iommu/arm-smmu-v3: Move the CD generation for S1 domains into a > function > iommu/arm-smmu-v3: Move allocation of the cdtable into > arm_smmu_get_cd_ptr() > iommu/arm-smmu-v3: Allocate the CD table entry in advance > iommu/arm-smmu-v3: Move the CD generation for SVA into a function > iommu/arm-smmu-v3: Build the whole CD in arm_smmu_make_s1_cd() > iommu/arm-smmu-v3: Start building a generic PASID layer > iommu/arm-smmu-v3: Make smmu_domain->devices into an allocated list > iommu/arm-smmu-v3: Make changing domains be hitless for ATS > iommu/arm-smmu-v3: Add ssid to struct arm_smmu_master_domain > iommu/arm-smmu-v3: Keep track of valid CD entries in the cd_table > iommu/arm-smmu-v3: Thread SSID through the arm_smmu_attach_*() > interface > iommu/arm-smmu-v3: Make SVA allocate a normal arm_smmu_domain > iommu/arm-smmu-v3: Keep track of arm_smmu_master_domain for SVA > iommu: Add ops->domain_alloc_sva() > iommu/arm-smmu-v3: Put the SVA mmu notifier in the smmu_domain > iommu/arm-smmu-v3: Consolidate freeing the ASID/VMID > iommu/arm-smmu-v3: Move the arm_smmu_asid_xa to per-smmu like vmid > iommu/arm-smmu-v3: Bring back SVA BTM support > iommu/arm-smmu-v3: Allow IDENTITY/BLOCKED to be set while PASID is > used > iommu/arm-smmu-v3: Allow a PASID to be set when RID is > IDENTITY/BLOCKED > iommu/arm-smmu-v3: Allow setting a S1 domain to a PASID > > .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 639 +++++----- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1036 +++++++++++------ > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 79 +- > drivers/iommu/iommu-sva.c | 4 +- > drivers/iommu/iommu.c | 12 +- > include/linux/iommu.h | 3 + > 6 files changed, 1024 insertions(+), 749 deletions(-) > > > base-commit: 98b23ebb0c84657a135957d727eedebd1280cbbf > -- > 2.43.2 > Thansks, Mostafa 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 77C11CD11BF for ; Sat, 23 Mar 2024 13:38:25 +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: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=1USua9XhJtuG7gm8MomgI/9TDcSje//8FCzCLyyw2lU=; b=hwF6ibYJNHwcOf +FC/4JebBO3ekhnUSR6NLy2vJ64ZRvbsqs5roRepwQhxg8uG0rvsbD3xJtAJwO4DyX/P8FYgV3oK0 Dh/hagKEN8VsuMUIlTYTn6gw5NAxUyb+dbNDvTyHXdkmA3TIeBmSJGddVhUX1PIl6si2CWHCM6Epa AqpKbQc9tfDHfJKRUwjAALg3v4K1f8hkgPrU4q7ftyExrVb/cI9D6sXo/XiXw0BKx3Kb2xkkeSspr JV5SJ8luyV82BN0ABqyuGMUqoeTw8lAiS9gJZMDkA+zOtKIhQtUVREv4jqN1BS06/Rhcrjm6HhyjE FZ/FuDq/Ks3sBuMEs6Wg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ro1Ze-0000000ATqb-2FVp; Sat, 23 Mar 2024 13:38:14 +0000 Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ro1Za-0000000ATq2-3LRC for linux-arm-kernel@lists.infradead.org; Sat, 23 Mar 2024 13:38:12 +0000 Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-41428b378b9so30405e9.1 for ; Sat, 23 Mar 2024 06:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1711201089; x=1711805889; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=X2lObstm1ERvlU1Nkp+L7+Kxf3ZnfKU4Wltlmi3CA3w=; b=mux9zTvaJA4V7jKV1WqLT+/fwA3nm4OM56bEvhpnjdCKY/ahSoS4cVCNMp3j1V+AFd 1aZrwC6802yHC/gkkY0XVp9OKD7jrhB+IeJEN+tYrspGcHYzpu79otE9t9G/PKUB/QmI Pmw0uhKooYCpom15IRD6LMKQZPevEt+2Y0x72WQOkF5JUpHMnsVZ4+ZfFxs5Gm8el8C6 mQgS6oKqKSWs9hKiHaGbHvAVBYURvMaNPESEHdHuHVpMI3AWn9EvmV6LJGJlgzbqZINK XqK60l8JuLY6MJTtRXRAdU/q5Dc0N5Ax0+rVr8lQ1CV0JVhjz3JYl7hlXpY4I4N+Ur7T nuXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711201089; x=1711805889; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=X2lObstm1ERvlU1Nkp+L7+Kxf3ZnfKU4Wltlmi3CA3w=; b=U0BbYy8at1GRDIFMIigD4sl2b1NxTKl22dYDY+JNiZlcgxNbL2ThEFkuQWK18pOwz0 qxWw3e8UsLXY5los5n2tgrPQOiyV5MuO/YBCpQf5GstMoPlmfgqu4mxtfVAQN0S4bIMk k29EZvLpqCjF0cwlGXyJsF4B3H37qtFabBVbTAj+ctSrDYq8rbpNTpDZOvs+CaHaaF1m mchhRodp9mFBfxADwLcJksEGCQDlpCLwIqfl91tr5txkfNLS0c5Li5M5kbxFj/B6yDpu MbsrfcEsu002huWWF7AlinFG7fPH/y7IQ8RAqSzo1rMRWGVReNJryxJC8lUhMMLtYmFL t0kg== X-Forwarded-Encrypted: i=1; AJvYcCW53dZLpEjToBF49U61d7P0suMT7Jkz3sDCpiU0EvicoBDQKISa3qZPAIOU7u3TmwjqpnFYwPqj8kAbR2ZTrU+bsg5M40Viv0xc17yWNO5cLM/ZR5Y= X-Gm-Message-State: AOJu0YyPtsKIibJRwdT1zSMeGJRo6J7rsNafxZicRPVN9/flKiL25BRi sU5pnm2JFv10XubwNIhXcOi1xpKKXHSzr+lPJRumluB+T+xt+nz/t/wdsjf34g== X-Google-Smtp-Source: AGHT+IH0YEkJX+tjrjcL88W6+N0EJawA09q6e87WEWXzxMNv3w8fp9nad4+db5XgANVhctp+gnzw1g== X-Received: by 2002:a05:600c:4856:b0:414:1400:a776 with SMTP id j22-20020a05600c485600b004141400a776mr641509wmo.5.1711201089204; Sat, 23 Mar 2024 06:38:09 -0700 (PDT) Received: from google.com (180.232.140.34.bc.googleusercontent.com. [34.140.232.180]) by smtp.gmail.com with ESMTPSA id n14-20020a5d51ce000000b0033e9fca1e49sm4446933wrv.60.2024.03.23.06.38.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Mar 2024 06:38:08 -0700 (PDT) Date: Sat, 23 Mar 2024 13:38:04 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: iommu@lists.linux.dev, Joerg Roedel , linux-arm-kernel@lists.infradead.org, Robin Murphy , Will Deacon , Eric Auger , Jean-Philippe Brucker , Moritz Fischer , Michael Shavit , Nicolin Chen , patches@lists.linux.dev, Shameerali Kolothum Thodi Subject: Re: [PATCH v5 00/27] Update SMMUv3 to the modern iommu API (part 2/3) Message-ID: References: <0-v5-9a37e0c884ce+31e3-smmuv3_newapi_p2_jgg@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0-v5-9a37e0c884ce+31e3-smmuv3_newapi_p2_jgg@nvidia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240323_063810_872247_F79FEB10 X-CRM114-Status: GOOD ( 40.74 ) 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 Hi Jason, On Mon, Mar 04, 2024 at 07:43:48PM -0400, Jason Gunthorpe wrote: > Continuing the work of part 1 this focuses on the CD, PASID and SVA > components: > > - attach_dev failure does not change the HW configuration. > > - Full PASID API support including: > - S1/SVA domains attached to PASIDs I am still going through the series, but I see at the end the main SMMUv3 driver has set_dev_pasid operation, are there any in-tree drivers that use that? (and how can I test it). > - 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 Can you please clarify what cases are expected to be hitless? >From what I see if ASID and TTB0 changes that would break the CD. > > Making the CD programming work like the new STE programming allows > untangling some of the confusing SVA flows. From there the focus is on > building out the core infrastructure for dealing with PASID and CD > entries, then keeping track of unique SSID's for ATS invalidation. > > The ATS ordering is generalized so that the PASID flow can use it and put > into a form where it is fully hitless, whenever possible. Care is taken to > ensure that ATC flushes are present after any change in translation. > > Finally we simply kill the entire outdated SVA mmu_notifier implementation > in one shot and switch it over to the newly created generic PASID & CD > code. This avoids the messy and confusing approach of trying to > incrementally untangle this in place. The new code is small and simple > enough this is much better than trying to figure out smaller steps. > > Once SVA is resting on the right CD code it is straightforward to make the > PASID interface functionally complete. > > It achieves the same goals as the several series from Michael and the S1DSS > series from Nicolin that were trying to improve portions of the API. > > This is on github: > https://github.com/jgunthorpe/linux/commits/smmuv3_newapi > > v5: > - Rebase on v6.8-rc7 & Will's tree > - Accomdate the SVA rc patch removing the master list iteration > - Move the kfree(to_smmu_domain(domain)) hunk to the right patch > - Move S1DSS get_used hunk to "Allow IDENTITY/BLOCKED to be set while > PASID is used" > v4: https://lore.kernel.org/r/0-v4-e7091cdd9e8d+43b1-smmuv3_newapi_p2_jgg@nvidia.com > - Rebase on v6.8-rc1, adjust to use mm_get_enqcmd_pasid() and eventually > remove all references from ARM. Move the new ARM_SMMU_FEAT_STALL_FORCE > stuff to arm_smmu_make_sva_cd() > - Adjust to use the new shared STE/CD writer logic. Disable some of the > sanity checks for the interior of the series > - Return ERR_PTR from domain_alloc functions > - Move the ATS disablement flow into arm_smmu_attach_prepare()/commit() > which lets all the STE update flows use the same sequence. This is > needed for nesting in part 3 > - Put ssid in attach_state > - Replace to_smmu_domain_safe() with to_smmu_domain_devices() > v3: https://lore.kernel.org/r/0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com > - Rebase on the latest part 1 > - update comments and commit messages > - Fix error exit in arm_smmu_set_pasid() > - Fix inverted logic for btm_invalidation > - Add missing ATC invalidation on mm release > - Add a big comment explaining that BTM is not enabled and what is > missing to enable it. > v2: https://lore.kernel.org/r/0-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com > - Rebased on iommmufd + Joerg's tree > - Use sid_smmu_domain consistently to refer to the domain attached to the > device (eg the PCIe RID) > - Rework how arm_smmu_attach_*() and callers flow to be more careful > about ordering around ATC invalidation. The ATC must be invalidated > after it is impossible to establish stale entires. > - ATS disable is now entirely part of arm_smmu_attach_dev_ste(), which is > the only STE type that ever disables ATS. > - Remove the 'existing_master_domain' optimization, the code is > functionally fine without it. > - Whitespace, spelling, and checkpatch related items > - Fixed wrong value stored in the xa for the BTM flows > - Use pasid more consistently instead of id > v1: https://lore.kernel.org/r/0-v1-afbb86647bbd+5-smmuv3_newapi_p2_jgg@nvidia.com > > Jason Gunthorpe (27): > iommu/arm-smmu-v3: Do not allow a SVA domain to be set on the wrong > PASID > iommu/arm-smmu-v3: Do not ATC invalidate the entire domain > iommu/arm-smmu-v3: Add a type for the CD entry > iommu/arm-smmu-v3: Add an ops indirection to the STE code > iommu/arm-smmu-v3: Make CD programming use arm_smmu_write_entry() > iommu/arm-smmu-v3: Consolidate clearing a CD table entry > iommu/arm-smmu-v3: Move the CD generation for S1 domains into a > function > iommu/arm-smmu-v3: Move allocation of the cdtable into > arm_smmu_get_cd_ptr() > iommu/arm-smmu-v3: Allocate the CD table entry in advance > iommu/arm-smmu-v3: Move the CD generation for SVA into a function > iommu/arm-smmu-v3: Build the whole CD in arm_smmu_make_s1_cd() > iommu/arm-smmu-v3: Start building a generic PASID layer > iommu/arm-smmu-v3: Make smmu_domain->devices into an allocated list > iommu/arm-smmu-v3: Make changing domains be hitless for ATS > iommu/arm-smmu-v3: Add ssid to struct arm_smmu_master_domain > iommu/arm-smmu-v3: Keep track of valid CD entries in the cd_table > iommu/arm-smmu-v3: Thread SSID through the arm_smmu_attach_*() > interface > iommu/arm-smmu-v3: Make SVA allocate a normal arm_smmu_domain > iommu/arm-smmu-v3: Keep track of arm_smmu_master_domain for SVA > iommu: Add ops->domain_alloc_sva() > iommu/arm-smmu-v3: Put the SVA mmu notifier in the smmu_domain > iommu/arm-smmu-v3: Consolidate freeing the ASID/VMID > iommu/arm-smmu-v3: Move the arm_smmu_asid_xa to per-smmu like vmid > iommu/arm-smmu-v3: Bring back SVA BTM support > iommu/arm-smmu-v3: Allow IDENTITY/BLOCKED to be set while PASID is > used > iommu/arm-smmu-v3: Allow a PASID to be set when RID is > IDENTITY/BLOCKED > iommu/arm-smmu-v3: Allow setting a S1 domain to a PASID > > .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 639 +++++----- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1036 +++++++++++------ > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 79 +- > drivers/iommu/iommu-sva.c | 4 +- > drivers/iommu/iommu.c | 12 +- > include/linux/iommu.h | 3 + > 6 files changed, 1024 insertions(+), 749 deletions(-) > > > base-commit: 98b23ebb0c84657a135957d727eedebd1280cbbf > -- > 2.43.2 > Thansks, Mostafa _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel