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 C7FB7C54EE9 for ; Tue, 20 Sep 2022 14:57:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A4A394000A; Tue, 20 Sep 2022 10:57:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 25459940007; Tue, 20 Sep 2022 10:57:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11CE894000A; Tue, 20 Sep 2022 10:57:14 -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 05720940007 for ; Tue, 20 Sep 2022 10:57:14 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B85521C5FBC for ; Tue, 20 Sep 2022 14:57:13 +0000 (UTC) X-FDA: 79932766746.09.32D1CC1 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf19.hostedemail.com (Postfix) with ESMTP id D6BC81A000D for ; Tue, 20 Sep 2022 14:57:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663685832; x=1695221832; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HvCoWXC5l0s95QFD5U8TCexD257nOCbyPLfqtS7D3tA=; b=VuZwBbkRTgz13vlemH2NtyQuiI1JINQSE3S7v0Kn8pNqeTSoS0ogTliR 6KR36u2sLSbiWd4P9WnAnd3T9bqJHwyNCi+MZ2CMkS+7Rrkvk0BaqJhqs we9NFiLpcT5xnJGXChWNk3iXi/pjExgLOWoRDNFDz5ZFvYISLeHGKUPlP yA5q48D4cJSmacqaRfCN4tUyWdtbrXC58v5M1cR/BrZzJJFGRoDGrEnLF wpRCOndZehEap8XJgED+m5Ks3yQLrj7qqx0umr2neE5Tu0Y3/GmutfXRD s0Vxd8Q/HE7UhGSM5eE4Lsfm5a3n/vWjFPgn9TeqGdICeaJmTtAdYE6Im w==; X-IronPort-AV: E=McAfee;i="6500,9779,10476"; a="326020256" X-IronPort-AV: E=Sophos;i="5.93,330,1654585200"; d="scan'208";a="326020256" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2022 07:57:02 -0700 X-IronPort-AV: E=Sophos;i="5.93,330,1654585200"; d="scan'208";a="687441949" 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; 20 Sep 2022 07:57:01 -0700 Date: Tue, 20 Sep 2022 14:57:04 +0000 From: Ashok Raj To: Jason Gunthorpe Cc: "Kirill A. Shutemov" , Jacob Pan , Ashok Raj , "Kirill A. Shutemov" , 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: References: <20220912224930.ukakmmwumchyacqc@box.shutemov.name> <20220914144518.46rhhyh7zmxieozs@box.shutemov.name> <20220914151818.uupzpyd333qnnmlt@box.shutemov.name> <20220914154532.mmxfsr7eadgnxt3s@box.shutemov.name> <20220914165116.24f82d74@jacob-builder> <20220915090135.fpeokbokkdljv7rw@box.shutemov.name> <20220915172858.pl62a5w3m5binxrk@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=1663685833; a=rsa-sha256; cv=none; b=ioIT/yAxg/hN6WhhDqOaGUkFD5c8QtK6CxK5hhPkB00kdYWW2ISUxfbCS1N5X1G5pAIOxx oL6Q/gd0Hh6/qgqgD5WTGE3RJCvUC9Oq2ZVgJcIOaSHInHxegJo2rQk6sYP0473jN0/RMV kKgiaDK4zw8wXghOGTesp0YPjA5DxFk= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=VuZwBbkR; spf=none (imf19.hostedemail.com: domain of ashok_raj@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=ashok_raj@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=1663685833; 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=7TwXPIUPNlxVrQeEDX/RFkTdUiAJ1SXKy/4VgbH6C4k=; b=XKb43YSj2qZB0TTmSKjpPFFOiFGkRdhjO4JY4CqV1am6r70RBgM0qwoyKkZ/anrbSlfHxh VcyMRn0DbuVl8B0GpnDW/EBaQJXtSVSVvIoPEcOFTpCUDPacJ92+li0mPg/p91tKU+4+UG EsctiH5HZhcznLOpCMxNL639qonj5EU= X-Rspamd-Server: rspam06 X-Rspam-User: X-Stat-Signature: u4roxemc8itwz6kmdfihryuo61na1wnj X-Rspamd-Queue-Id: D6BC81A000D Authentication-Results: imf19.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=VuZwBbkR; spf=none (imf19.hostedemail.com: domain of ashok_raj@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=ashok_raj@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-HE-Tag: 1663685832-476483 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 Tue, Sep 20, 2022 at 10:14:54AM -0300, Jason Gunthorpe wrote: > On Thu, Sep 15, 2022 at 08:28:58PM +0300, Kirill A. Shutemov wrote: > > > @@ -31,7 +33,17 @@ int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max) > > min == 0 || max < min) > > return -EINVAL; > > > > + /* Serialize against address tagging enabling */ > > + if (mmap_write_lock_killable(mm)) > > + return -EINTR; > > + > > + if (!arch_can_alloc_pasid(mm)) { > > + mmap_write_unlock(mm); > > + return -EBUSY; > > + } > > This has nothing to do with "allocating pasid" > > Rather should be: "is the CPU page table compatible with the IOMMU HW > page table walker" Thanks Jason, this certainly looks like a more logical way to look at it rather than the functional association of allocating pasids. > > For this I would rather have a function that queries the format of the > page table under the mm_struct and we have enum values like > INTEL_NORMAL and INTEL_LAM as possible values. > > The iommu driver will block incompatible page table formats, and when > it starts up it should assert something that blocks changing the > format. > > Jason >