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 9FA28ECAAD8 for ; Fri, 23 Sep 2022 09:38:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3514980009; Fri, 23 Sep 2022 05:38:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D99A80007; Fri, 23 Sep 2022 05:38:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1856F80009; Fri, 23 Sep 2022 05:38:37 -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 05ED280007 for ; Fri, 23 Sep 2022 05:38:37 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CC7B6A0F4F for ; Fri, 23 Sep 2022 09:38:36 +0000 (UTC) X-FDA: 79942850232.28.D51201B Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf24.hostedemail.com (Postfix) with ESMTP id 3CD7A180004 for ; Fri, 23 Sep 2022 09:38:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663925915; x=1695461915; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=r/i0i0SbliPYGtD9iHbXgqL0bdCmXHR1pywmanT4gGo=; b=BVvLw2sM3HwsiUGKWp+uDtHRjrSP65kNH7OGxCumfp99ZJRiypsfCfVG YtBWXhlqKNyp1lzlJZknyAELNork2JULR1xy9X/miTNuhnoDWFijqkb4h 7Ge6GcHOgaME7xWyRykNEG7R+kfkIA1MfOPPS/xoHj4bLxfiQu+lzS67v 3craeJGpzLozzObUXzpV4CevkqbnC1sgQRrC266zkYR3Z7TxcdCZ29+PO p7CsEs9Gtk3A7nfK7P8u9xGYKh+/Hsi8Oea8SwWSdl5SUg67UAEqFsRXI 935bo7Swv9DgWlVjFhTlTtLJrHoGopyMZ/SYW/Lojs+qiCFlg+PH7d9nT w==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="283651956" X-IronPort-AV: E=Sophos;i="5.93,337,1654585200"; d="scan'208";a="283651956" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 02:38:33 -0700 X-IronPort-AV: E=Sophos;i="5.93,337,1654585200"; d="scan'208";a="709242525" Received: from pameiner-mobl2.amr.corp.intel.com (HELO box.shutemov.name) ([10.252.58.236]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 02:38:29 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 83761104B0F; Fri, 23 Sep 2022 12:38:26 +0300 (+03) Date: Fri, 23 Sep 2022 12:38:26 +0300 From: "Kirill A. Shutemov" To: Ashok Raj Cc: Jason Gunthorpe , Dave Hansen , 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 Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling Message-ID: <20220923093826.kjad4qe3clwybeh6@box.shutemov.name> References: <20220914154532.mmxfsr7eadgnxt3s@box.shutemov.name> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663925916; a=rsa-sha256; cv=none; b=TNqYZuuAO88L+i41BQmV+5tUy1e0U11mK/jdQjTaiXbTLk69KH5x986SlgLyao+zSikcNf 6OrLZ9d05oMoRbjyc6SUZ7F6auXFZk0VfFnWsmPjA3xNGdmM1WXAxu79bUlYvcEAqSh/fb fEQeB+zh8XUvlzlDfYVv7dy/aSY7SRg= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=BVvLw2sM; spf=none (imf24.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663925916; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=v693ZJ2Tf678cnVVtdxGuCND/UOrod7XVRBMzShy64E=; b=1o4juEdQ3Qi1o3jL1QSGA4VbPpV/EAu0FTXC8ViCUtWm/Qjj2s759ObHBYsgXsItjkSA/k TxBVS4znVWynTMpVecRNqaT3XCTOePVvKkfgcKJ5ou6o/pvgw9mWvsgFKIxlTpxwxqP6sr RPUU4CeIwc6FWlH3BW7TyNdLnyMnGJE= X-Stat-Signature: qjwpdb7ign788htxdtta9x1f3ubyfb8r X-Rspamd-Queue-Id: 3CD7A180004 X-Rspam-User: X-Rspamd-Server: rspam11 Authentication-Results: imf24.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=BVvLw2sM; spf=none (imf24.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-HE-Tag: 1663925914-636030 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 Thu, Sep 22, 2022 at 10:27:45PM -0700, Ashok Raj wrote: > On Fri, Sep 23, 2022 at 03:42:39AM +0300, Kirill A. Shutemov wrote: > > On Wed, Sep 21, 2022 at 03:11:34PM -0300, Jason Gunthorpe wrote: > > > On Wed, Sep 21, 2022 at 10:11:46AM -0700, Dave Hansen wrote: > > > > > > > Are you saying that any device compatibility with an mm is solely > > > > determined by the IOMMU in play, so the IOMMU code should host the mm > > > > compatibility checks? > > > > > > Yes, exactly. Only the HW entity that walks the page tables needs to > > > understand their parsing rules and in this case that is only the IOMMU > > > block. > > > > But device has to know what bits of the virtual address are significant to > > handle device TLB lookup/store correctly, no? > > For a device that also cares about tagging, yes. But in the current > world we don't have such devices. IOMMU only knows about the shared cr3 > we placed in the PASID table entries to walk page-tables. I hope the > page-tables don't factor the meta-data bits correct? Correct. Page tables contain only physical addresses, so they have no exposure to tags in the virtual addresses. > 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. So where to put compatibility check that can cover both device and IOMMU, considering that in the future they can get aware about tagged pointers? -- Kiryl Shutsemau / Kirill A. Shutemov