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;
Date:   Wed, 14 Sep 2022 08:31:56 -0700
From:   Ashok Raj <ashok.raj@intel.com>
To:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
CC:     "Kirill A. Shutemov" <kirill@shutemov.name>,
        Ashok Raj <ashok_raj@linux.intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "Andy Lutomirski" <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, <x86@kernel.org>,
        Kostya Serebryany <kcc@google.com>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        Andrey Konovalov <andreyknvl@gmail.com>,
        "Alexander Potapenko" <glider@google.com>,
        Taras Madan <tarasmadan@google.com>,
        "Dmitry Vyukov" <dvyukov@google.com>,
        "H . J . Lu" <hjl.tools@gmail.com>,
        Andi Kleen <ak@linux.intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        Jacon Jun Pan <jacob.jun.pan@intel.com>,
        Jason Gunthorpe <jgg@nvidia.com>,
        Joerg Roedel <joro@8bytes.org>, Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling
Message-ID: <YyHz7H0uyqG58b3E@araj-MOBL2.amr.corp.intel.com>
References: <20220830010104.1282-1-kirill.shutemov@linux.intel.com>
 <YxDvpLb77lwb8zaT@araj-dh-work>
 <20220904003952.fheisiloilxh3mpo@box.shutemov.name>
 <20220912224930.ukakmmwumchyacqc@box.shutemov.name>
 <20220914144518.46rhhyh7zmxieozs@box.shutemov.name>
 <YyHvF2K7ELVSTGvB@araj-MOBL2.amr.corp.intel.com>
 <20220914151818.uupzpyd333qnnmlt@box.shutemov.name>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20220914151818.uupzpyd333qnnmlt@box.shutemov.name>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?u5LA2whjuYYl1eR4WwaagnFIw2bRYuVsh2qoTC5BdKPq1WVmKK5aPKXjkvee?=
 =?us-ascii?Q?hi/Zjrrh4og6KJr7V8WVhmBlbLMj7QMMVpIQUH5+o6VDWXxsX9g1ye/KAdQM?=
 =?us-ascii?Q?5dbM5btkfYBbURE46LrkydwXa1H0/8AChax945BNK90v0Dp8YXMajg6EC6b3?=
 =?us-ascii?Q?wT8yuOHln0J8AYRPcWPYZoGT5O3R4l5+Jvi4JU9kohMt1XO6L5GkImQJOJLX?=
 =?us-ascii?Q?aPiPNYo2Hb7IOhlo+UeV4C7e36iWdYiawCvhJtGB6u1fGW3Fj3bPUmRMo7Xr?=
 =?us-ascii?Q?KmzdSIP02sHHaf5pYKjAAizn5KFhm09WF9su18T3o4FNprPUBr6bc1aCOMw+?=
 =?us-ascii?Q?zrQ0/XDmUTJb5XeRLjUdvHM08vSthvHG2AtmTyuXXyB2Ai1WpG+4V3BYXsW7?=
 =?us-ascii?Q?rhPesOH/2QXjTctxgXvpBQruzfO2OkGx/ZDcdhklDjJmfpeATStFxDjJ5Gwy?=
 =?us-ascii?Q?pvInY6npJoUvvhMvU/MiQNr9bui203tWKA3iVHWLJWWfDxEjhgbCCJ4bHvLo?=
 =?us-ascii?Q?XU03lBjx24h4SU5XUvUUZBRHLhWxVB3HBj88yObLN4xyjG7UQVw7PLQFgJy+?=
 =?us-ascii?Q?+3njLU/FfCVqooBbsiq8cXkkEbLQ6NRqSU+TR41NjOpd7vwrw83WdSFY3Kt+?=
 =?us-ascii?Q?WHs3MKwOYeVsU7t6QZN6ewwqM539hB+jkRa/3YHvP51eIwd0cml6ocoUPaqh?=
 =?us-ascii?Q?YHzrA5hgKDEEuyGHm9lB0s6aX7RPpVgNsiNPTBUv8zNk3XiWLP02vI+ZOlEJ?=
 =?us-ascii?Q?SsGdJ0sxYv2W2Qh/oFXK5RG6R9VldPdsNRjz0IiUF7xkym+TxVd3PUfaL1Aj?=
 =?us-ascii?Q?c7GS2CNH5Ep1R8ataIO0kr31wLAetykJEwRv5DbmBPs/k63l7WbOs528t+WJ?=
 =?us-ascii?Q?6uBDw0WLll34DBZXhR6qeNN7mrwrk4A/0RCFN97PnjGeDz5rwTf76/QFFy7Z?=
 =?us-ascii?Q?muRuqtmjzXaq0uy4fOfquoJek9DZ6+P264XAktn60T/nV+R1eTzy2bwfQHlk?=
 =?us-ascii?Q?q25lrLzK8tcKVomGp8dBTGFeu7twsPei9N/EgI/zXNRsoWzU6hovv8gkRTU2?=
 =?us-ascii?Q?GUjrR0L055pOG70GgcNMh899GW/D+vCyf7OdCy8eJnkG3ju6H7c2ZlrOlaTT?=
 =?us-ascii?Q?Of4x7zSc75ltej+m95d2xuKYn658sSZMY6rHtqecTbNk5XPKtHgWbwBvbCLV?=
 =?us-ascii?Q?hO6zc44Zf74x5xMo3HBPPrRwRco4JLCiB5Hhr4eEtCvV4pmBCEFMLTGH4OYs?=
 =?us-ascii?Q?A8lkRDLPZ0aMUX7I4G0Gxa+rWoCJpXeUWtR/sKYUOfOnvqfOgzqspuosKD2j?=
 =?us-ascii?Q?46t+d8JwXgJeAMvxSlqAnrKux6o7hQvHot8qOcg6bbKoiYOCS3zGxmmYvEjG?=
 =?us-ascii?Q?tdmAzzR2BFprI952zYFoia5J5X5w2OWtLuh/97KWcSuGSs1XyZCvFBhaIo0P?=
 =?us-ascii?Q?scEntK0Si7RwailXIXjoU4RX7jMEOeCXaMSY/EMQQo/lAXUuDxPhHyRJtVSo?=
 =?us-ascii?Q?2UN/LgMfE7yRL46jSt1LtraSG10Bj8oglhn+DmDUTk1yIH85TQM7CMc6qzsK?=
 =?us-ascii?Q?aJBL1UwWyjYlYEfIEoTWboJhukLmbTGmbab2SOwR?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 0652c804-0e3d-4724-c199-08da9666456c
X-MS-Exchange-CrossTenant-AuthSource: SJ1PR11MB6201.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2022 15:32:02.3650
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: LfOH7mH2W1N15nfobyYvkQwfI5kZRbfzzVbr4rwLuBQdasAfZDr3W9z6KPF62jUccGhaUIkUAGy+rTJLiXtvMA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5367
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.