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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDF91C433F5 for ; Thu, 23 Sep 2021 23:22:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C2BE06023B for ; Thu, 23 Sep 2021 23:22:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243549AbhIWXYK (ORCPT ); Thu, 23 Sep 2021 19:24:10 -0400 Received: from mga06.intel.com ([134.134.136.31]:38482 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235628AbhIWXYJ (ORCPT ); Thu, 23 Sep 2021 19:24:09 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10116"; a="284976067" X-IronPort-AV: E=Sophos;i="5.85,318,1624345200"; d="scan'208";a="284976067" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2021 16:22:37 -0700 X-IronPort-AV: E=Sophos;i="5.85,318,1624345200"; d="scan'208";a="514303216" Received: from agluck-desk2.sc.intel.com (HELO agluck-desk2.amr.corp.intel.com) ([10.3.52.146]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2021 16:22:37 -0700 Date: Thu, 23 Sep 2021 16:22:35 -0700 From: "Luck, Tony" To: Andy Lutomirski Cc: Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "Peter Zijlstra (Intel)" , Dave Hansen , Lu Baolu , Joerg Roedel , Josh Poimboeuf , Dave Jiang , Jacob Jun Pan , Raj Ashok , "Shankar, Ravi V" , iommu@lists.linux-foundation.org, the arch/x86 maintainers , Linux Kernel Mailing List Subject: Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting Message-ID: References: <20210920192349.2602141-1-fenghua.yu@intel.com> <20210920192349.2602141-6-fenghua.yu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 23, 2021 at 04:09:18PM -0700, Andy Lutomirski wrote: > On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote: > I think this is unnecessarily complicated because it's buying in to the > existing ISA misconception that PASID has anything to do with a task. > A PASID belongs to an mm, full stop. Now the ISA is nasty and we have > tasks that have *noticed* that their mm has a PASID and tasks that have > not noticed this fact, but that should be irrelevant to essentially > everything except the fault handler. > > So just refcount the thing the obvious way: take a reference when you > stick the PASID in the mm_struct and drop the reference in __mmdrop(). > Problem solved. You could probably drop it more aggressively in > __mmput(), and the comment explaining why is left as an exercise to the > reader -- if a kernel thread starts doing ENQCMD, we have worse things > to worry about :) That doesn't match well with the non-x86 usage of PASIDs. The code there bumps the reference count on each device bind, and decrements on each device unbind. If we don't keep a reference count for each task that has IA32_PASID set up we could have this sequence 1) Process binds to a PASID capable device 2) Task uses ENQCMD, so PASID MSR is set up. 3) Process unbinds the device, reference count on PASID goes to zero. PASID is freed. PASID is reallocated to another task. 4) Task from step #2 uses ENQCMD to submit a descriptor and device now processes virtual addresses based on mappings in the new task. Now you might say that at step 3 we need to hunt down all the tasks that have PASID enabled and disabled ... but that's the same painful code that we avoided when we said that we would not make Linux hand out a PASID to all existing tasks in a process on the first bind operation. -Tony