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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CE66C6FA8B for ; Fri, 23 Sep 2022 14:18:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232585AbiIWOSu (ORCPT ); Fri, 23 Sep 2022 10:18:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232593AbiIWOSr (ORCPT ); Fri, 23 Sep 2022 10:18:47 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 766531296A1 for ; Fri, 23 Sep 2022 07:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663942726; x=1695478726; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=2ZW7KOwhuGX8/vjus2UIoe6mKHPYuInZCvASKmTZu1I=; b=no2i8CjaoPZcsWUelYPEzTXxHEHTyInYaLGiLeihSNmpUy/f0by2mR56 AyqOp6PH0z9EorhJopO4XVRp4JmwxlVicfzsi2srSQri+e6rtdPbHYS0C KmFmBHbBs61lLNfBt592zTfCnc1gYKXxhdl9643lwWggEhYikbpr8XtKr m9NwbgamIroyCajFPNnmdGjf3ZPqcIJysK3A5UnASR8wFfia4x0UJxuR7 R2kjBKgKYjjO/gcq2CY73j2XYQhCFuPsQFiI0UMxYx/oWJcEQMcmiHTMl tAKNFDfoKYThIkrorqERhCWVUk5fkUUxCn0of6oumG3CjFTBz725C8MwM w==; X-IronPort-AV: E=McAfee;i="6500,9779,10479"; a="280964983" X-IronPort-AV: E=Sophos;i="5.93,339,1654585200"; d="scan'208";a="280964983" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 07:18:46 -0700 X-IronPort-AV: E=Sophos;i="5.93,339,1654585200"; d="scan'208";a="865306263" Received: from hanjulee-mobl1.amr.corp.intel.com (HELO [10.252.138.32]) ([10.252.138.32]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 07:18:43 -0700 Message-ID: Date: Fri, 23 Sep 2022 07:18:42 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling Content-Language: en-US To: Jason Gunthorpe , "Kirill A. Shutemov" Cc: Ashok Raj , Jacob Pan , "Kirill A. Shutemov" , Ashok Raj , Dave Hansen , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joerg Roedel References: <20220914165116.24f82d74@jacob-builder> <20220915090135.fpeokbokkdljv7rw@box.shutemov.name> <20220915172858.pl62a5w3m5binxrk@box.shutemov.name> <562dec4d-a39f-b517-58a3-45f691a2d10a@intel.com> <20220923004239.ma2gfrmoezsff4ro@box.shutemov.name> <20220923093826.kjad4qe3clwybeh6@box.shutemov.name> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. If the device is unaware of the tags, then how does device TLB invalidation work? Would all device TLB flushes be full flushes of the devices TLB? If something tried to use single-address invalidation, it would need to invalidate every possible tag alias because the device wouldn't know that the tags *are* tags instead of actual virtual addresses.