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:   Mon, 12 Sep 2022 17:23:16 -0700
From:   Ashok Raj <ashok.raj@intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
CC:     Jacob Pan <jacob.jun.pan@intel.com>,
        Ashok Raj <ashok_raj@linux.intel.com>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        "Kirill A. Shutemov" <kirill.shutemov@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>,
        Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling
Message-ID: <Yx/Nc9gyAhEZ16Ai@araj-MOBL2.amr.corp.intel.com>
References: <20220830010104.1282-1-kirill.shutemov@linux.intel.com>
 <YxDvpLb77lwb8zaT@araj-dh-work>
 <20220904003952.fheisiloilxh3mpo@box.shutemov.name>
 <Yxtk4gMbcVgTKzKg@araj-dh-work>
 <20220912133935.3bb3e247@jacob-builder>
 <356d4ad1-f7d8-b8ff-3b63-819a64bf5b9f@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <356d4ad1-f7d8-b8ff-3b63-819a64bf5b9f@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?dfOk+Funl2TjOUbq4q7JWl7eMjj8Egez9FXuYovLJQgQ80O/MzOqtaFFkFt6?=
 =?us-ascii?Q?Ki/u9PIi/smLNEKTWqCjv+kUhY8Fe+j55Hf5U3mgR3Bci1CPK33AxLbQg0SH?=
 =?us-ascii?Q?1iJVMVcF/ghrxfBxIiwKCj6f3v7ELmmEu3kV3R2asJ0ZsFHGvACvWs+TzfO/?=
 =?us-ascii?Q?N0OtnON6JT1XA+H+JgCgXjQpqX+rVoEh7vEM41NcwpTbV3QNHEg29r/d1pm7?=
 =?us-ascii?Q?2JHoQsE/zOb6GGVUAHWRhzc0jYS4pSVmK/Vkmm/KmSEI3qoCHtIOf3JAgXPa?=
 =?us-ascii?Q?5yfp4brMHZg1ewREU6igXTgnW9ORckUPosHhCVkjPjaOO9z7dzeGvokbxEcg?=
 =?us-ascii?Q?Acz4ID18hPWhOxaK0goecjQKPqzjb1iD0WMPWHKSvjGWKAlLo7633WGs/Ri3?=
 =?us-ascii?Q?MWcRWTfDGzUUbKJns9WleZwjWCNKWmgqDPrUHiQeuFNIOZKzjr5Ti1kjuKNa?=
 =?us-ascii?Q?MrYDP9uTCUUNSfHmNm1poTIABzE2OvM04yLiVlXBuhnbq1OslmvT9jjcCIve?=
 =?us-ascii?Q?XV9zgL/L/KQkV9fm9E6Xm9z9yC/d4JhfnwBmgjSEPtWDlLbGofVf2uReWKHG?=
 =?us-ascii?Q?x5h+3YvUqfP83bxhQcYql6fdX+Z6UbaRFI9GOmlbXp1m1+RwfXiGmcTfG/7C?=
 =?us-ascii?Q?i9S8BelIxXGtRzC5aQm5N69Fdmv5autCuQnjqrifpJn/SRHTG4OhSiN7W53B?=
 =?us-ascii?Q?0aXekowByjrHz/xFhYU5k+hMvpz+M3mVDpl5LbRcug2eoAMQqBEkbbqVMtaQ?=
 =?us-ascii?Q?cvIqC0TFOKXg+lxCInYQWsWE5y87GgZVk4OMRldcN1bUy4iyZ37c/pH/lka2?=
 =?us-ascii?Q?szccIN2d/nvLjX0AhQ/YCtAaIVtzBq7fQHwwhY4wHw4RJwvtLvAScgBpioUx?=
 =?us-ascii?Q?DYy2F+/48RuDbUgKRRdnfv4OTWscma2qajZTPRTvxXsgqXRKpp0Wkknotp8F?=
 =?us-ascii?Q?F+Y5o//HLu8Is5v0vFhTEUEXwTf9abM3pDtdxuG1DlWli5J/ZC/9TX6vB4HH?=
 =?us-ascii?Q?tSzAX388wyRxm6HE4fRJwIt1acv/aCdbQdQd2uTND2WipUVCInw+31RDpeev?=
 =?us-ascii?Q?Xljo7SbVmhKLPOquD7PSG5UahFs7AuQvW8Ed8nOkyLlo2+S4bEoNvkIXwu4r?=
 =?us-ascii?Q?7HAtHfRn+ArYhXx0IB/sOHWDaThRR1HaY77OUzYvhpAKjg0sM8oGNv3lE2CN?=
 =?us-ascii?Q?EwVb7TtANwspeGLuIBq0V8AwlMLNo8O/S5ATjQvoYh3ECj5Ax9Zh7K/YpStR?=
 =?us-ascii?Q?M5A2ga7BhIli0PY8qhKY3zUMjAEB8S1j6cu13bvBXUax4h9P6kjxAw/r4BSb?=
 =?us-ascii?Q?qrzSGJTqzDcubivybNzBXGTtbiB0qu7meAuq7JYi7+fzLEBwjAkyqQV7aWW5?=
 =?us-ascii?Q?PTgPPV7/pVf0YBXzk3v4TCpXlxtJ+90pAITSJriEfhFACMzazKA1ufmtb1ZK?=
 =?us-ascii?Q?9ljw+wlyYqL/daMpgWZBpfmghntUW21PLVueA8xKpJd3AVjbQKq3JNA0UP/G?=
 =?us-ascii?Q?UFWv8vXOhztg/mtg10cCYPAkHJfw+6N1TMall2tYfgpNjTNANLrVyO4rpQSz?=
 =?us-ascii?Q?UCFo+jSxBVJ9CPhZSKv/ok/ZBuJ70S0sT/4oAyrA?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a0827506-cc04-43b9-1f77-08da951e2a08
X-MS-Exchange-CrossTenant-AuthSource: SJ1PR11MB6201.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2022 00:23:22.1517
 (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: Hc03VNWsMaTDWnU8cB6aQwo55Tm+zwb46v6S+fg5FYtzMFqi+CnlAonbnnsF7rvUn4uHCE+tO//x+o1h6YYy4g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR11MB6415
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 Mon, Sep 12, 2022 at 02:41:56PM -0700, Dave Hansen wrote:
> On 9/12/22 13:39, Jacob Pan wrote:
> >>> +	if (pasid_valid(mm->pasid) && !forced) {
> > I don't think this works since we have lazy pasid free.  for example,
> > after all the devices did sva_unbind, mm->pasid  we'll remain valid until
> > mmdrop(). LAM  should be supported in this case.
> 
> Nah, it works fine.
> 
> It just means that the rules are "you can't do LAM if your process
> *EVER* got a PASID" instead of "you can't do LAM if you are actively
> using your PASID".
> 
> We knew that PASID use would be a one-way trip for a process when we
> moved to the simplified implementation.  This is just more fallout from
> that.  It's fine.

Agree.

> 
> > Perhaps, we could introduce another prctl flag for SVA, PR_GET_SVA?
> > Both iommu driver and LAM can set/query the flag. LAM applications may not
> > be the only ones want to know if share virtual addressing is  on.
> 
> I don't think it's a good idea to add yet more UABI around this issue.
> Won't the IOMMU folks eventually get their hardware in line with LAM?
> Isn't this situation temporary?

This is more than just the IOMMU change, since this involves device end,
ability to report tagging feature, communicating the width to ignore
etc. I suspect PCIe changes are required for the device end which would
be a long pole. 

I suspect this would be moderately permanent :-) memory tagging is more
of a niche use case, and hurting general IO devices has lots of design
touch points that makes it difficult to close in short order.