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 D5DE2ECAAD8 for ; Fri, 23 Sep 2022 16:23:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0DCB680008; Fri, 23 Sep 2022 12:23:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08C7480007; Fri, 23 Sep 2022 12:23:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6E6E80008; Fri, 23 Sep 2022 12:23:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D91C380007 for ; Fri, 23 Sep 2022 12:23:45 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A972CABA11 for ; Fri, 23 Sep 2022 16:23:45 +0000 (UTC) X-FDA: 79943871210.28.F668B7B Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf14.hostedemail.com (Postfix) with ESMTP id D873B100010 for ; Fri, 23 Sep 2022 16:23:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663950224; x=1695486224; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Ohgz4vUkNpBw0/bFzU4TdicddjZG3hCBlJt1N4VxeBU=; b=K+UBR8PweBiPM6o8WOFABtNwO1W654VWlRpbQbO7xVf7qFmdqbkqZw4w EA60dd8NexhsNMXqKBq5x//A9TPTj6N7VawpDWZjEAaX8cyNhvmuLvQ+5 zJH5yL0L8eB38tJ05TqyKTSdt8fHs+kIdS+1XL6SbC0qemnr2hNPxVclh IUBx1AdxmPbv3NepPgCb/RDj0xbVViacRMUtX3sUOlaDwDq5HkfT3J+R8 6EUZg2ej1JfMlKAUrwh8Ree36crmxR4n+gI6PQ+ETGaWtZHPhgS+GyfCe BdcRzQWRqs06FbO6gnXE2QqIWX7JvPHtSELCC8v8Z6iib4Ut9ICLmLWGL w==; X-IronPort-AV: E=McAfee;i="6500,9779,10479"; a="300609616" X-IronPort-AV: E=Sophos;i="5.93,339,1654585200"; d="scan'208";a="300609616" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 09:23:42 -0700 X-IronPort-AV: E=Sophos;i="5.93,339,1654585200"; d="scan'208";a="651003049" Received: from hanjulee-mobl1.amr.corp.intel.com (HELO [10.252.138.32]) ([10.252.138.32]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 09:23:40 -0700 Message-ID: <21e4a613-cf21-6d90-17e7-91aa960bdafa@intel.com> Date: Fri, 23 Sep 2022 09:23:40 -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: Ashok Raj Cc: Jason Gunthorpe , "Kirill A. Shutemov" , 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: <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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663950225; a=rsa-sha256; cv=none; b=2fqrkcTLJM2hYPLXBPYmi5MePeq1tTmKo2u1vpq3M+hsDrbZrcE4SIXY9o8YrMSBlaeP+W sRSkw+ksI5ZpRtnPF6sl8MenVadQkDXoAtnwougEYQ+maRi6JnbvoekidRoAxTjWO0lf1P wFzZOljzW13RDADotTaeOgUSZgWxM6o= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663950225; 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=6qQ+eq4nibr/Ku2NavzFVBkW9JiPbz0ZkF+/jAKNHUU=; b=pX9NPnwtJqbFzDjk2pxkFSPN73pjUSW6eKMY90N7VddRVltbcwMJCATtijP5qaEjklXBQ5 T68vZfaxK2uGuNnfTJVlFogNAEG3qkZ68J+LCLNolKsL0GwkmUQpgFGhkfMmNjuVQMFgPQ 4d6QTKDNv9J89NFWtyyhUmtOqeqkz8c= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=K+UBR8Pw; spf=pass (imf14.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Stat-Signature: mqch4k984ubgsg9efwek9rry4am4g3du X-Rspamd-Queue-Id: D873B100010 Authentication-Results: imf14.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=K+UBR8Pw; spf=pass (imf14.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam02 X-Rspam-User: X-HE-Tag: 1663950223-293864 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 08:44, Ashok Raj wrote: >> But, the point that Kirill and I were getting at is still that devices >> *have* a role to play here. The idea that this can be hidden at the >> IOMMU layer is pure fantasy. Right? > If you *can't* send tagged memory to the device, what is the > role the device need to play? > > For now you can only send proper VA's that are canonical. Today, yes, you have to keep tagged addresses away from devices. They must be sequestered in a place that only the CPU can find them. The observation that Kirill and I had is that there are thing that are done solely on the device today -- like accessing a translated address twice -- without IOMMU involvement. We were trying to figure out how that would work in the future once tagged addresses are exposed to devices and they implement all the new PCI magic. After our private chat, I think the answer is that devices *have* a role to play. Device-side logic must know how to untag memory before asking for translation or even *deciding* to ask for address translation. But, hopefully, the communicating that untagging information to the device will be done in a device-agnostic, standardized way, just how PASIDs or ATS are handled today.