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 AC9A9C6FA82 for ; Fri, 23 Sep 2022 15:31:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 499BD80014; Fri, 23 Sep 2022 11:31:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 448D480007; Fri, 23 Sep 2022 11:31:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E9E980014; Fri, 23 Sep 2022 11:31:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1FC3980007 for ; Fri, 23 Sep 2022 11:31:18 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E55D812046E for ; Fri, 23 Sep 2022 15:31:17 +0000 (UTC) X-FDA: 79943738994.21.6A29A53 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf18.hostedemail.com (Postfix) with ESMTP id 4E8731C0014 for ; Fri, 23 Sep 2022 15:31:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663947076; x=1695483076; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=v96tuYGGMJYs8ptS79bcD/41j+v8We2inkrTBpBMyfk=; b=iuOEqRMyqv+sVgWWWQJebn4NJZSG7Hi6kNtY/xpLrfOSEeSx6cEBwIfO 597uDTrCWeSQ0Co8oxFMMnAtHN96gFGVHpOaD0E4POB6di/Vi/0j8XljQ L2y1wkQ+6dIVjkASC/kdfTQfHh6jYRYhmpz6aPIXCiaPL8m0gDyEZeWuQ 1/EHpL1vdQZyPgv6R4OAIqtv5dv+fWRX9RH4ddQFWsNxVVz5Q8WJwTEZk qvyhGnW5qVSzVFXQncv0cq9AwEdAnHCkHft8mAOcUnjwLrh2LRp6yi3Bn 7KNWS56acdEDOHT9CgR67L9gKt5TryLUx31TsrRsBS+nfB3kqCLdlzlh2 w==; X-IronPort-AV: E=McAfee;i="6500,9779,10479"; a="386903934" X-IronPort-AV: E=Sophos;i="5.93,339,1654585200"; d="scan'208";a="386903934" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 08:31:14 -0700 X-IronPort-AV: E=Sophos;i="5.93,339,1654585200"; d="scan'208";a="745829440" Received: from hanjulee-mobl1.amr.corp.intel.com (HELO [10.252.138.32]) ([10.252.138.32]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 08:31:13 -0700 Message-ID: Date: Fri, 23 Sep 2022 08:31:13 -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: <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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663947076; a=rsa-sha256; cv=none; b=DnH9oFmQdhPYfj5josfan1oeGKAhGdLB2fxsakLOjkFo5TBTIlLbAG1/5wxI7Dv1f6vfUx h52EBT2HBjFdxeNg/u6t5Oz+umh7uFCXQ39x39JKEanxSbaG8HGbXTk6Of7PE7eoSGOuz6 9vYUyDH8HYS/U0EQCrFG1IxaQveMdro= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=iuOEqRMy; spf=pass (imf18.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663947076; 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=CAeZL6wWKDfwogB/CIlN6qDAofoMpLVHw43t2aZjg58=; b=017kyFa0VwVZSqxCezW70ABv/H9pozJhGimPIJhrDIrEHACaWmJnFkee1Vr7j9+4MLxkeY xTafERlBEIcmY3z2JUfUGrli0XgS0ZdGyTpN/qp/NJqI7W81RGEEJCZ9JIOZlfOSW1Bwp7 1O7/RX0fP+8ndYpodpvQnRgqy5PoAH8= X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 4E8731C0014 Authentication-Results: imf18.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=iuOEqRMy; spf=pass (imf18.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Stat-Signature: 9ei138agqpsynwz9iqr5num7kxrzyexe X-HE-Tag: 1663947076-323907 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:28, Ashok Raj wrote: >> >> 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 > This is coming a full circle now :-) > > Since the device doesn't understand tagging, SVM and tagging aren't > compatible. If you need SVM, you can only send sanitized pointers to the > device period. In fact our page-request even looks for canonical checks > before doing the page-faulting. > >> 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. > Once tagging is extended into the PCI SIG, and devices know to work with > them, so will the IOMMU, then they can all play in the same field. Until > then they are isolated, or let SVM only work with untagged VA's. 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?