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 A4BD9C6FA86 for ; Thu, 15 Sep 2022 17:32:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC5F16B0073; Thu, 15 Sep 2022 13:32:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C74FF6B0074; Thu, 15 Sep 2022 13:32:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3CD88D0001; Thu, 15 Sep 2022 13:32:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A2A216B0073 for ; Thu, 15 Sep 2022 13:32:25 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7089BAC3A1 for ; Thu, 15 Sep 2022 17:32:25 +0000 (UTC) X-FDA: 79915013850.06.5F8F674 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf03.hostedemail.com (Postfix) with ESMTP id 69EEA2009F for ; Thu, 15 Sep 2022 17:32:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663263144; x=1694799144; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=b+eGOyzBNzmsIjgmd3FH7KDt5YKAIkB20CJEC/+9RbQ=; b=UsUE7P5sF3EUoucrjy4gNeClYHuKnDpIcHGRVO8+LGlF60fpaRBMAbhK w5gyswMbCU4rXAyxGUuZVsbTndorLCLqZ5bpmrB9IfEvV8KMU3CbTs8R1 g7r/WL6sk0EOsyZrCdOSZXZJqtsC6Te7jss9sLAOHf2C4VSWrMPyrksq4 D5ZZhNu2zGhrjU8P+YM+CHk7Mmx2RUYGk8SGviUdI8Ytaw6q1w2GRz6m2 Qgc+13V56gMv718n6JImJK10OLXdKRzgHaSq4CUXeB+ZNKDF0iKQLL/C/ sDHtLmXXgAC8Y4GCxOC5SPnwX2aF8tEtrSWeKc5tWVjUNKBg+FoC7oKhp Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10471"; a="362753163" X-IronPort-AV: E=Sophos;i="5.93,318,1654585200"; d="scan'208";a="362753163" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2022 10:29:06 -0700 X-IronPort-AV: E=Sophos;i="5.93,318,1654585200"; d="scan'208";a="679624817" Received: from gnogale1-mobl2.amr.corp.intel.com (HELO box.shutemov.name) ([10.251.209.66]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2022 10:29:00 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 6559810466F; Thu, 15 Sep 2022 20:28:58 +0300 (+03) Date: Thu, 15 Sep 2022 20:28:58 +0300 From: "Kirill A. Shutemov" To: Jacob Pan Cc: Ashok Raj , "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, Jason Gunthorpe , Joerg Roedel Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling Message-ID: <20220915172858.pl62a5w3m5binxrk@box.shutemov.name> References: <20220904003952.fheisiloilxh3mpo@box.shutemov.name> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220915090135.fpeokbokkdljv7rw@box.shutemov.name> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663263144; a=rsa-sha256; cv=none; b=NUIluN3NDK9ZyTcPBoArjdC+XG0DNF7jNEQvSrPmmHp8Mxb6HWMOK89JtQmaEgnLwBN1VU TNhd5Lv6s0iU1B6p+aCNVl6YQv2VQyuJHRQvfwtg2uI6pQIilgdaSVtf/GAwhlTSSxYsb5 iSZyq014/dN7r8Ra8jutEpnhHjIVg5Q= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=UsUE7P5s; spf=none (imf03.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.100) 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=1663263144; 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=ZBVa+DLDawPsJXWG2WOItggZ4Nnba44QUeyx9QkgCkc=; b=yeee/89kPM8TlPYOTGMzHzI+ZRDelSFqHvPz0N+XlhLqF5p8Iwv4i6kcxBlPq3uaxAejuu froVwuyoQEJWzCWHFxYFRjlz6u2wcwK3HOgFvcAjWvO2lhZreyNnj5ChPSSHd5/ynJNuw3 2ILJYVI2Xn3oFO8LecL5gzD1EkRMeAM= X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=UsUE7P5s; spf=none (imf03.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Rspamd-Server: rspam03 X-Stat-Signature: fac4tywwdmstfbszakqaou15pw6nnjji X-Rspamd-Queue-Id: 69EEA2009F X-HE-Tag: 1663263144-886616 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 15, 2022 at 12:01:35PM +0300, Kirill A. Shutemov wrote: > On Wed, Sep 14, 2022 at 04:51:16PM -0700, Jacob Pan wrote: > > Hi Kirill, > > > > On Wed, 14 Sep 2022 18:45:32 +0300, "Kirill A. Shutemov" > > wrote: > > > > > On Wed, Sep 14, 2022 at 08:31:56AM -0700, Ashok Raj wrote: > > > > On Wed, Sep 14, 2022 at 06:18:18PM +0300, Kirill A. Shutemov wrote: > > > > > > > > > > > > > > > > > > The patch below implements something like this. It is PoC, > > > > > > > > > build-tested only. > > > > > > > > > > > > > > > > > > To be honest, I hate it. It is clearly a layering violation. > > > > > > > > > It feels dirty. But I don't see any better way as we tie > > > > > > > > > orthogonal features together. > > > > > > > > > > > > > > > > > > Also I have no idea how to make forced PASID allocation if > > > > > > > > > LAM enabled. What the API has to look like? > > > > > > > > > > > > > > > > Jacob, Ashok, any comment on this part? > > > > > > > > > > > > > > > > I expect in many cases LAM will be enabled very early (like > > > > > > > > before malloc is functinal) in process start and it makes PASID > > > > > > > > allocation always fail. > > > > > > > > > > > > > > > > Any way out? > > > > > > > > > > > > > > We need closure on this to proceed. Any clue? > > > > > > > > > > > > Failing PASID allocation seems like the right thing to do here. If > > > > > > the application is explicitly allocating PASID's it can opt-out > > > > > > using the similar mechanism you have for LAM enabling. So user takes > > > > > > responsibility for sanitizing pointers. > > > > > > > > > > > > If some library is using an accelerator without application > > > > > > knowledge, that would use the failure as a mechanism to use an > > > > > > alternate path if one exists. > > > > > > > > > > > > I don't know if both LAM and SVM need a separate forced opt-in (or i > > > > > > don't have an opinion rather). Is this what you were asking? > > > > > > > > > > > > + Joerg, JasonG in case they have an opinion. > > > > > > > > > > My point is that the patch provides a way to override LAM vs. PASID > > > > > mutual exclusion, but only if PASID allocated first. If we enabled > > > > > LAM before PASID is allcoated there's no way to forcefully allocate > > > > > PASID, bypassing LAM check. I think there should be one, no? > > > > > > > > Yes, we should have one for force enabling SVM too if the application > > > > asks for forgiveness. > > > > > > What is the right API here? > > > > > It seems very difficult to implement a UAPI for the applications to > > override at a runtime. Currently, SVM bind is under the control of > > individual drivers. It could be at the time of open or some ioctl. > > > > Perhaps, this can be a platform policy via some commandline option. e.g. > > intel_iommu=sva_lam_coexist. > > I think it has to be per-process, not a system-wide handle. > > Maybe a separate arch_prctl() to allow to enable LAM/SVM coexisting? > It would cover both sides of the API, relaxing check for both. Maybe something like the patch below. Build tested only. I really struggle with naming here. Any suggestions on what XXX has to be replaced with? I don't think it has to be limited to LAM as some other tagging implementation may come later. diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h index 2fdb390040b5..0a38b52b7b5e 100644 --- a/arch/x86/include/asm/mmu.h +++ b/arch/x86/include/asm/mmu.h @@ -12,6 +12,8 @@ #define MM_CONTEXT_UPROBE_IA32 BIT(0) /* vsyscall page is accessible on this MM */ #define MM_CONTEXT_HAS_VSYSCALL BIT(1) +/* Allow LAM and SVM coexisting */ +#define MM_CONTEXT_XXX BIT(2) /* * x86 has arch-specific MMU state beyond what lives in mm_struct. diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h index 3736f41948e9..d4a0994e5bc7 100644 --- a/arch/x86/include/asm/mmu_context.h +++ b/arch/x86/include/asm/mmu_context.h @@ -113,6 +113,8 @@ static inline void mm_reset_untag_mask(struct mm_struct *mm) mm->context.untag_mask = -1UL; } +#define arch_can_alloc_pasid(mm) \ + (!mm_lam_cr3_mask(mm) || (mm->context.flags & MM_CONTEXT_XXX)) #else static inline unsigned long mm_lam_cr3_mask(struct mm_struct *mm) diff --git a/arch/x86/include/uapi/asm/prctl.h b/arch/x86/include/uapi/asm/prctl.h index a31e27b95b19..3b77d51c7e6c 100644 --- a/arch/x86/include/uapi/asm/prctl.h +++ b/arch/x86/include/uapi/asm/prctl.h @@ -23,5 +23,6 @@ #define ARCH_GET_UNTAG_MASK 0x4001 #define ARCH_ENABLE_TAGGED_ADDR 0x4002 #define ARCH_GET_MAX_TAG_BITS 0x4003 +#define ARCH_XXX 0x4004 #endif /* _ASM_X86_PRCTL_H */ diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 9aa85e74e59e..111843c9dd40 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -793,6 +793,11 @@ static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits) goto out; } + if (pasid_valid(mm->pasid) && !(mm->context.flags & MM_CONTEXT_XXX)) { + ret = -EBUSY; + goto out; + } + if (!nr_bits) { ret = -EINVAL; goto out; @@ -911,6 +916,12 @@ long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2) (unsigned long __user *)arg2); case ARCH_ENABLE_TAGGED_ADDR: return prctl_enable_tagged_addr(task->mm, arg2); + case ARCH_XXX: + if (mmap_write_lock_killable(task->mm)) + return -EINTR; + task->mm->context.flags |= MM_CONTEXT_XXX; + mmap_write_unlock(task->mm); + return 0; case ARCH_GET_MAX_TAG_BITS: { int nr_bits; diff --git a/drivers/iommu/iommu-sva-lib.c b/drivers/iommu/iommu-sva-lib.c index 106506143896..ed76cdfa3e6b 100644 --- a/drivers/iommu/iommu-sva-lib.c +++ b/drivers/iommu/iommu-sva-lib.c @@ -2,6 +2,8 @@ /* * Helpers for IOMMU drivers implementing SVA */ +#include +#include #include #include @@ -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; + } + mutex_lock(&iommu_sva_lock); + /* Is a PASID already associated with this mm? */ if (pasid_valid(mm->pasid)) { if (mm->pasid < min || mm->pasid >= max) @@ -46,6 +58,7 @@ int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max) mm_pasid_set(mm, pasid); out: mutex_unlock(&iommu_sva_lock); + mmap_write_unlock(mm); return ret; } EXPORT_SYMBOL_GPL(iommu_sva_alloc_pasid); diff --git a/include/linux/mmu_context.h b/include/linux/mmu_context.h index b9b970f7ab45..1649b080d844 100644 --- a/include/linux/mmu_context.h +++ b/include/linux/mmu_context.h @@ -28,4 +28,8 @@ static inline void leave_mm(int cpu) { } # define task_cpu_possible(cpu, p) cpumask_test_cpu((cpu), task_cpu_possible_mask(p)) #endif +#ifndef arch_can_alloc_pasid +#define arch_can_alloc_pasid(mm) true +#endif + #endif -- Kiryl Shutsemau / Kirill A. Shutemov