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 05998ECAAD1 for ; Thu, 1 Sep 2022 17:45:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A440880036; Thu, 1 Sep 2022 13:45:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A1B148000D; Thu, 1 Sep 2022 13:45:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E30D80036; Thu, 1 Sep 2022 13:45:05 -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 801DB8000D for ; Thu, 1 Sep 2022 13:45:05 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4655B1601B6 for ; Thu, 1 Sep 2022 17:45:05 +0000 (UTC) X-FDA: 79864242570.24.65A3A52 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf04.hostedemail.com (Postfix) with ESMTP id 4A7DD4004E for ; Thu, 1 Sep 2022 17:45:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662054304; x=1693590304; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=/59lUBPazWehnHqG6Yhvtz5YTUoyACoFaPW03K4rfaA=; b=LGr/A96zmRPOjV3DZinoW+yDvub3agj0kLKUNNCbAtVaQTEFc5d/iZD1 M6iO6ggeCUQ+PcX5YI119XeealMLprPWFxH06E8okVfH1CoK5GrAjwcUi 9GKUpB2s10KzD7e9pVeRG3sUViLFgQAxfyuCUsp84HWC/TLse00/MSAsZ qtFDnQee3E0cl1937xG2hQM4OfEiRRyexOOivTb9PEhoCYd0fP1Ncs1Da IaohzE9jFWGefq9iHVLauTtZ+QgZz2MrwPv0vvmzmge5Ox8jcLsyWf/HU eL8Elgu1IGcbzz17W9Uk52plwqhOTs4MYeuScytRyb7ycr7o52GdnIqRA w==; X-IronPort-AV: E=McAfee;i="6500,9779,10457"; a="296567173" X-IronPort-AV: E=Sophos;i="5.93,281,1654585200"; d="scan'208";a="296567173" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 10:45:02 -0700 X-IronPort-AV: E=Sophos;i="5.93,281,1654585200"; d="scan'208";a="680961760" Received: from araj-dh-work.jf.intel.com (HELO araj-dh-work) ([10.165.157.158]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 10:45:02 -0700 Date: Thu, 1 Sep 2022 17:45:08 +0000 From: Ashok Raj To: "Kirill A. Shutemov" Cc: 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, Jacon Jun Pan , Ashok Raj Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling Message-ID: References: <20220830010104.1282-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220830010104.1282-1-kirill.shutemov@linux.intel.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662054304; 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=4RF23DntA+VD3tIeMK2HjomvFgiCveS8kDsaa/J8lso=; b=8qirNpYwyhSf1ysPb0b3rBkToVv1u/TCMw97YsN7NBTARtlpePBj9uRnaPoSEiZtRCiBNF 6sfgVbPjLWFMLUepMaLBQ1KSUA3A4Lrc0ei1c1xnqWSHGdxG54VxoMG4lE8W8LtZ3FSS+q xhDG0Lz5UG5+Qz4GTHN2g//glTUKwUQ= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="LGr/A96z"; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf04.hostedemail.com: domain of ashok_raj@linux.intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=ashok_raj@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662054304; a=rsa-sha256; cv=none; b=wubeAixGjMIAvIpjjAz9P/BP36yn6Zpr1sGwLC3OdP3j2EB01/eht0GbSjWr5lQmg0gd8v K2LhHfWCHaj+kxyjaWfIhBa5/inYC9r0qNILZNuvY7A6x6fo0NCnu+wv0fxiRLsnBQekTM m0BgsjWkhxL0XrNd300MHUlvsgNTKho= Authentication-Results: imf04.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="LGr/A96z"; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf04.hostedemail.com: domain of ashok_raj@linux.intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=ashok_raj@linux.intel.com X-Rspamd-Queue-Id: 4A7DD4004E X-Stat-Signature: whh8siqyiezft18wb1ra3nhcktgqjuio X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1662054304-900317 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: Hi Kirill, On Tue, Aug 30, 2022 at 04:00:53AM +0300, Kirill A. Shutemov wrote: > Linear Address Masking[1] (LAM) modifies the checking that is applied to > 64-bit linear addresses, allowing software to use of the untranslated > address bits for metadata. We discussed this internally, but didn't bubble up here. Given that we are working on enabling Shared Virtual Addressing (SVA) within the IOMMU. This permits user to share VA directly with the device, and the device can participate even in fixing page-faults and such. IOMMU enforces canonical addressing, since we are hijacking the top order bits for meta-data, it will fail sanity check and we would return a failure back to device on any page-faults from device. It also complicates how device TLB and ATS work, and needs some major improvements to detect device capability to accept tagged pointers, adjust the devtlb to act accordingly. Both are orthogonal features, but there is an intersection of both that are fundamentally incompatible. Its even more important, since an application might be using SVA under the cover provided by some library that's used without their knowledge. The path would be: 1. Ensure both LAM and SVM are incompatible by design, without major changes. - If LAM is enabled already and later SVM enabling is requested by user, that should fail. and Vice versa. - Provide an API to user to ask for opt-out. Now they know they must sanitize the pointers before sending to device, or the working set is already isolated and needs no work. 2. I suppose for any syscalls that take tagged pointers you would maybe relax checks for how many bits to ignore for canonicallity. This is required so user don't need to do the same for everything sanitization before every syscall. If you have it fail, the library might choose a less optimal path if one is available. Cheers, Ashok