Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 23 Sep 2022 11:42:39 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Ashok Raj <ashok.raj@intel.com>,
        Jacob Pan <jacob.jun.pan@intel.com>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        Ashok Raj <ashok_raj@linux.intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
        Kostya Serebryany <kcc@google.com>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        Andrey Konovalov <andreyknvl@gmail.com>,
        Alexander Potapenko <glider@google.com>,
        Taras Madan <tarasmadan@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        "H . J . Lu" <hjl.tools@gmail.com>,
        Andi Kleen <ak@linux.intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Joerg Roedel <joro@8bytes.org>
Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling
Message-ID: <Yy3F3+PA47mzX/2o@nvidia.com>
References: <20220915172858.pl62a5w3m5binxrk@box.shutemov.name>
 <562dec4d-a39f-b517-58a3-45f691a2d10a@intel.com>
 <YytFGqv5V4T8lbM8@araj-MOBL2.amr.corp.intel.com>
 <f1aac14e-380c-f76f-84bb-fdff56207d2f@intel.com>
 <YytT1hfRZdb9GYQK@nvidia.com>
 <20220923004239.ma2gfrmoezsff4ro@box.shutemov.name>
 <Yy1D0dLdqTr7ya71@a4bf019067fa.jf.intel.com>
 <20220923093826.kjad4qe3clwybeh6@box.shutemov.name>
 <Yy2cfppqkf85hPT7@nvidia.com>
 <fd1f54b5-010d-da65-3989-d8cf727261c7@intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fd1f54b5-010d-da65-3989-d8cf727261c7@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?YUyx7eRMfOQ2pPtAjfGp0je50xox2b3FAx85qZdkwaFtgy5vnc/4bLmaJcbh?=
 =?us-ascii?Q?bXvSXb7k5ABWSKK+1hzt/JW/abH1TU3dhzLr4E5/P1dVvEtmhhU9zSpVM7J3?=
 =?us-ascii?Q?KGD/I7ttje9OleqCxkj9+zVV5v7iQ8DHQh9aRuIm4clP7IeXjvORXMxCAVkM?=
 =?us-ascii?Q?ENxTBC/1MCndSdFPNNIvazxU0UVF+byana1sTG04ZIzKf8VcQqCrBrHbvUzv?=
 =?us-ascii?Q?mkPsoDENYmeZ9IqaBtBZ2TbAQj2njMgNFpA08cI99LowB0gJjlA4aCxhrnww?=
 =?us-ascii?Q?jiO078bpp3GFzhD9gwlb+uqLXkmHCvdYUzLIwBpmaGVG1VxMEXn2ECaMpLQT?=
 =?us-ascii?Q?LU3YSdsdFRP+n8EZ84j4iG9J6zQtwVV7e0R+rePr6MfryWalN2nWBCXS5oce?=
 =?us-ascii?Q?7SGpNmoq1Yroy8QFggsyuITYXkm2QAXmuMYTEussEOONbG6q69qS9XlKSMtF?=
 =?us-ascii?Q?ArqMhlewavNRbNU6pR5TfzS+q5V5ACqjyYnMhJmj6Nu0ik5re0nOfnuFxEEX?=
 =?us-ascii?Q?NxSjl/B/Fqmm/D+0kgbzbIAIMoqpFJIGoNgnTLRd2zu+gCb0aOfaqrtth1u0?=
 =?us-ascii?Q?8d1hjN6E6InbephhMFma5YmQGsgw8nbAc1t+spCWtt+PwBnYRJHBY1XaOgtS?=
 =?us-ascii?Q?uI8fNv/0e6Go5ngyJbivs3KnkpuPTrZZSntt/Dhk2QFMLze2tTglK0kVOwkC?=
 =?us-ascii?Q?Osg8/n5DTSlfmo5BhavCjNG27fW7LpeINawtHRXHZT4dHjQjac2DaAWlCmgd?=
 =?us-ascii?Q?Am+aNYyixhp5yd+YvxsBQPbRlVg1jh1q12LHMpQam8UArqa3mjubWK09gPGV?=
 =?us-ascii?Q?8Nh4izs2flM6Io6Ijy8+4gLVbljXF8DKKHxkiQVorjVzhevuy3+1V3uvz5k/?=
 =?us-ascii?Q?Gb8WgaYFsMBtyz4kW2uw2NlRg9Q6jyzlbyf/tfO52AR3V7EKKzSLOeRvn6P1?=
 =?us-ascii?Q?RLcD53286hijazynIlCgH2e110T+KypLMpMAziTktNxElhKAdH+/+N87O2BB?=
 =?us-ascii?Q?mYlbEsCOS10RQsK6/bMj73RACzqwvQr6Lz/6bPAteWoQc9/C6081UTT+oPno?=
 =?us-ascii?Q?ik2CZYUj34GxbAJTbXyfVjKX9HuI63LfOSQScOQbVh+v19l7ytjFaKFdeN/q?=
 =?us-ascii?Q?nYf4CyVUPGjiISWJxCJmV6z2/+RHixQwrS0YGuDPeO6jBTaUMTyVjy7e3Luy?=
 =?us-ascii?Q?ZlHVJQDJEQ2JVx6fDMvxE9z4Mgc85SfELG4ht36si/vh+i4M+psz4oTPUVhb?=
 =?us-ascii?Q?zWW/CG3SU0inItzCIlS33AsDCCPYkGVqg/lDxq8NVGQl8YIeFUHHGJgfy0EF?=
 =?us-ascii?Q?Rl766a2ZFtHCrGIpYIvKcrroyXQihoAo2Nx+9QmUAyw7rrksgWY3KddFMh4t?=
 =?us-ascii?Q?g8/vaZaiJ9OOXvKQU/YbpFV2sRuaHnchyFryGl+KuejCg7kUW0AkoQP9Ag5m?=
 =?us-ascii?Q?ugHeUkhp+CgfqtclUP6lNieSjDtGm2U+VnzSoZ/yONMQFQSpwNvc5G9LWZo2?=
 =?us-ascii?Q?O7Y9m/KhTioo1NSF28ohe3RYWObl8P9c5oBvMJaAmt9SpiFUg1aawsYFhZbD?=
 =?us-ascii?Q?ATjFSPj00pPBvgBSoXlD23iSMwdeYJN6oONb6IWv?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 27a602b8-fa05-41c2-81d3-08da9d71decc
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4192.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2022 14:42:42.2875
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 1TkeDg0ZGQjqehIVs0fqkZYIzigiiS88ud8A24U2o4R16eEk/VHdzp97HB4M5tWC
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR12MB5651
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Sep 23, 2022 at 07:18:42AM -0700, Dave Hansen wrote:
> On 9/23/22 04:46, Jason Gunthorpe wrote:
> > On Fri, Sep 23, 2022 at 12:38:26PM +0300, Kirill A. Shutemov wrote:
> >>> So I would assume an untagged pointer should just be fine for the IOMMU
> >>> to walk. IOMMU currently wants canonical addresses for VA.
> >> Right. But it means that LAM compatibility can be block on two layers:
> >> IOMMU and device. IOMMU is not the only HW entity that has to be aware of
> >> tagged pointers.
> > Why does a device need to care about this? What do you imagine a
> > device doing with it?
> > 
> > The userspace should program the device with the tagged address, the
> > device should present the tagged address on the bus, the IOMMU should
> > translate the tagged address the same as the CPU by ignoring the upper
> > bits.
> 
> Is this how *every* access works?  Every single device access to the
> address space goes through the IOMMU?
> 
> I thought devices also cached address translation responses from the
> IOMMU and stashed them in their own device-local TLB.  

Ah, you are worried about invalidation.

There is an optional PCI feature called ATS that is this caching, and
it is mandatory if the IOMMU will use the CPU page table.

In ATS the invalidation is triggered by the iommu driver in a device
agnostic way.

The PCI spec has no provision to invalidate with a mask, only linear
chunks of address space can be invalidated.

Presumably when someone wants to teach the iommu to process LAM they
will also have to teach the the PCI spec how to do LAM too.

I would not like to see a world where drivers have to deal with this.
ATS is completely transparent to the driver, it should stay that
way. Devices should handle LAM through some PCI SIG agnostic approach
and that will be contained entirely in the iommu driver.

Jason