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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37A87C6FA82 for ; Fri, 23 Sep 2022 14:18:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 73D1C80008; Fri, 23 Sep 2022 10:18:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C4F580007; Fri, 23 Sep 2022 10:18:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 565D980008; Fri, 23 Sep 2022 10:18:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 42ED580007 for ; Fri, 23 Sep 2022 10:18:51 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7790A409AC for ; Fri, 23 Sep 2022 14:18:49 +0000 (UTC) X-FDA: 79943556378.02.76BB608 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf19.hostedemail.com (Postfix) with ESMTP id CF2131A000E for ; Fri, 23 Sep 2022 14:18:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663942727; x=1695478727; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=2ZW7KOwhuGX8/vjus2UIoe6mKHPYuInZCvASKmTZu1I=; b=bMOJnCdrzMdD3V3Xi6hXpCwBQe3OWv676T2ohbNGfXARE1XUAkG2tcyO FTUwgbHlaz8uLItmKfMX7d+2nXQgkjQaLenFmUmg8MpSOqK6rdTUzB31q kOpgSGOYRMqP8JCLT3Kussx+IaEvYJhYvoLVJmxuvES3YHsJ3O40ZR993 DIMDJFMtUEV6P9EnX0yiKKbwPdDp+2WfTSzhay6DMCjMvPLZPxEvkXzSK tE0AnT1fR8jDeZq9Hp8qvumaUztUfk9DbteNyIKD89pmtFAS0RWrF3TEN NNfXjMQbmSBT+2FZwbeVGTg1UHE6uTtJAopRtcDNTeHxYuFlqWqnNN36Q Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10479"; a="362413401" X-IronPort-AV: E=Sophos;i="5.93,339,1654585200"; d="scan'208";a="362413401" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.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 ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=bMOJnCdr; spf=pass (imf19.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663942729; a=rsa-sha256; cv=none; b=Nib0RP5S6TxfZyXImaPhEgOtJiTWoyzHgTzVjjqz0urfL7g09u10UyniAptJ2pSrFD7cSo 5yP0NBXkjvQExJTEw/bVMmVJyhqCPP8vO734GQrlBUPq8ziPhjzfVnuhUB8x7y+c9gAFSt yRmGAtlxG3l/CSH7HYe2vow2wmKp/Hw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663942729; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IkszcL+rtnH8DHa1dQj8KCRG0Ns0Rh5p+ha/ZHCgI+Y=; b=4MZDL4Ovue0udr4OPCSQv3nEqCe4MhhTQR5VvMXMOplQyHAs7Wvk84odYttERRUxvXfBIm hOuhyBVSqFGE0z1w3eSL0qZauxOt1MVcbZKZmpazSQEMWhp/J/LzK/AgGVcIAOGuu4WS8/ bXpnZ999FB+09LvkANJcg+/gzmwWGdE= Authentication-Results: imf19.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=bMOJnCdr; spf=pass (imf19.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Stat-Signature: kpk1yj67sdeqootnxtfhnf41qfs5gzmh X-Rspamd-Queue-Id: CF2131A000E X-Rspamd-Server: rspam09 X-HE-Tag: 1663942727-67563 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.