Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp4359384pxb; Sat, 5 Feb 2022 10:59:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJyeyqt9Aw1ymofRXHvKO3yv9MVFiZXd2HeaOu7zX75yEgevJlATMQ9teLGvRcBOjwUVzlaz X-Received: by 2002:a17:90b:38c7:: with SMTP id nn7mr5596187pjb.124.1644087563342; Sat, 05 Feb 2022 10:59:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644087563; cv=none; d=google.com; s=arc-20160816; b=YckFu5Kt8n2dj6+W/5wuhBCuM4ap8lBnyBAcxbP0EgLtfMwF/uSRBZedELV7uf+jnA mNuBFn/muN3WnKlwL82FiTqVphSqeTlzZu4zVI5Kf3LklkelxOyzA4aoG7IBiUp7Cnno AR7Wdn+n6mL8vaQC5bICmZBEe+PhLTA3bKaDoFYPuoQWetw41FPgKby/shAbdc5BqXyJ fQuVfRWcfdaj1syRz86I6EQhNCUd4cbcEm0s9IHrO1JpuyEzNIA38aSCdTX5Hcz8o9WX Kubc+NUhDIwwG7bbDOHVsNadIVAE3b+N8FU6CBPaWS/WtDVM7498zNpi5pB+62GpPSJu uw7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=NEq+ui03rkBdlfu2GxpBVdX6s9oqKgKzGmhe/F/LJjo=; b=djXY6P4hAgRsgDQ07dgI2bbB6M0DVq8Pfu+AAIcO3B2MpWe7PdYnBwiLfvhaNx+X3+ DoiwK7BhaU0MjpFp/MdWDoc+TcaAimLDJeVwQCvDnef+zlnowu/Y39JvSPuQ/fazepFW lqiIaV2lwb85BKYoVLmkQJG7LJEwOF6yzUPwAde/NMVDuPnKnwUXXiApkxCX1yWmvm50 mHW5cYcyPGDgMY/IXWHBOezUT4bffmU6C9h6SYQ2YhXXGbm4Fe6JPOAFswpvA2WgLueM zCU1er4Ksj5NNMO6WHTDVS4KWVSlKT2K4kSDOBgf60l65eiZp/nJ3+psFyCE2PFTN9gr 3JLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZFwLYyvx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 15si5419756pgt.260.2022.02.05.10.59.12; Sat, 05 Feb 2022 10:59:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZFwLYyvx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378077AbiBEAZn (ORCPT + 99 others); Fri, 4 Feb 2022 19:25:43 -0500 Received: from mga12.intel.com ([192.55.52.136]:35453 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231908AbiBEAZm (ORCPT ); Fri, 4 Feb 2022 19:25:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644020742; x=1675556742; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=seqp1K4lOkMWSGy1QhjFDo6IEhqcwqjPfzMecDFWN9w=; b=ZFwLYyvxCzmk5Nrjx85Sj6V0uKDqIPO2daFfUMW+Vew/+/izlEvxpvOA wmOb61KGsutm3y0sMHYn4YA+E2sLZWaT3oiJwnTyedGvv2EvcfLLfTp10 juvh/adooxISGZkZtIM1ngUfFzsUZboSarIndRGvHLSgluVJ7o++Nm1ar f5QrTLzjOlYqihUbK1lqLDUYNOoxcmZQQqBERSZ6oytVqyD/08OIWN56X urIPcMpR6hyqPADw1T+CZ4syZLaCiZDEamcsgVQNA+oUaZ7mh4/mGkYLR HEIHyONZZLLcLN2VW2w+xJvzkNhGxkpToT3rfPhDZcL/gP/AClZklti4B Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10248"; a="228438547" X-IronPort-AV: E=Sophos;i="5.88,344,1635231600"; d="scan'208";a="228438547" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Feb 2022 16:25:42 -0800 X-IronPort-AV: E=Sophos;i="5.88,344,1635231600"; d="scan'208";a="539361229" Received: from otcwcpicx3.sc.intel.com ([172.25.55.73]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Feb 2022 16:25:41 -0800 Date: Fri, 4 Feb 2022 16:25:34 -0800 From: Fenghua Yu To: Thomas Gleixner Cc: Dave Hansen , Ingo Molnar , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , Tony Luck , Lu Baolu , Joerg Roedel , Josh Poimboeuf , Jacob Pan , Ashok Raj , Ravi V Shankar , iommu@lists.linux-foundation.org, x86 , linux-kernel Subject: Re: [PATCH v3 04/11] kernel/fork: Initialize mm's PASID Message-ID: References: <20220128202905.2274672-1-fenghua.yu@intel.com> <20220128202905.2274672-5-fenghua.yu@intel.com> <87wniab4kb.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wniab4kb.ffs@tglx> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Thomas, On Sat, Feb 05, 2022 at 12:22:12AM +0100, Thomas Gleixner wrote: > On Fri, Jan 28 2022 at 12:28, Fenghua Yu wrote: > > A new mm doesn't have a PASID yet when it's created. Initialize > > the mm's PASID on fork() or for init_mm to INVALID_IOASID (-1). > > I must be missing something here. > > > diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h > > index aa5f09ca5bcf..c74d1edbac2f 100644 > > --- a/include/linux/sched/mm.h > > +++ b/include/linux/sched/mm.h > > @@ -8,6 +8,7 @@ > > #include > > #include > > #include > > +#include > > > > /* > > * Routines for handling mm_structs > > @@ -433,4 +434,13 @@ static inline void membarrier_update_current_mm(struct mm_struct *next_mm) > > } > > #endif > > > > +#ifdef CONFIG_IOMMU_SVA > > +static inline void mm_pasid_init(struct mm_struct *mm) > > +{ > > + mm->pasid = INVALID_IOASID; > > +} > > +#else > > +static inline void mm_pasid_init(struct mm_struct *mm) {} > > +#endif > > + > > #endif /* _LINUX_SCHED_MM_H */ > > So this adds mm_pasid_init() to linux/sched/mm.h which replaces: > > > -static void mm_init_pasid(struct mm_struct *mm) > > -{ > > -#ifdef CONFIG_IOMMU_SVA > > - mm->pasid = INIT_PASID; > > -#endif > > -} > > - > > I.e. already existing code which is initializing mm->pasid with > INIT_PASID (0) while the replacement initializes it with INVALID_IOASID > (-1). > > The change log does not have any information about why INIT_PASID is the > wrong initialization value and why this change is not having any side > effects. I should add the following info in the commit message to explain why change INIT_PASID (0) to INVALID_IOASID (-1): INIT_PASID (0) is reserved for kernel legacy DMA PASID. It cannot be allocated to a user process. Initialize the process's PASID to 0 may cause confusion that why the process uses reserved kernel legacy DMA PASID. Initializing the PASID to INVALID_IOASID (-1) explicitly tells the process doesn't have a valid PASID yet initially. Is it OK for you? > > It neither mentions why having this in a global available header makes > sense when the only call site is in the C file from which the already > existing function is removed. This series defines three helpers mm_pasid_init(), mm_pasid_set(), and mm_pasid_drop() in mm because they handle the pasid member in mm_struct and should be part of mm operations. I explained why mm_pasid_set() and mm_pasid_drop() are defined in mm, but I didn't explain why mm_pasid_init() is define in mm. Is it OK to add the following explanation on why mm_pasid_init() is defined? mm_pasid_init() is defined in mm and replaces mm_init_pasid() because the PASID init operation initializes the pasid member in mm_struct and should be part of mm operations. Thanks, -Fenghua