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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70584C433F5 for ; Wed, 29 Sep 2021 02:11:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A819613DB for ; Wed, 29 Sep 2021 02:11:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243716AbhI2CMv convert rfc822-to-8bit (ORCPT ); Tue, 28 Sep 2021 22:12:51 -0400 Received: from mga02.intel.com ([134.134.136.20]:63923 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243681AbhI2CMt (ORCPT ); Tue, 28 Sep 2021 22:12:49 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10121"; a="212096871" X-IronPort-AV: E=Sophos;i="5.85,331,1624345200"; d="scan'208";a="212096871" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2021 19:11:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,331,1624345200"; d="scan'208";a="476492026" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga007.jf.intel.com with ESMTP; 28 Sep 2021 19:11:09 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 28 Sep 2021 19:11:08 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 28 Sep 2021 19:11:08 -0700 Received: from fmsmsx610.amr.corp.intel.com ([10.18.126.90]) by fmsmsx610.amr.corp.intel.com ([10.18.126.90]) with mapi id 15.01.2242.012; Tue, 28 Sep 2021 19:11:08 -0700 From: "Luck, Tony" To: "Yu, Fenghua" CC: "Hansen, Dave" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "Peter Zijlstra (Intel)" , Lu Baolu , Joerg Roedel , Josh Poimboeuf , "Jiang, Dave" , "Pan, Jacob jun" , "Raj, Ashok" , "Shankar, Ravi V" , "iommu@lists.linux-foundation.org" , "the arch/x86 maintainers" , Linux Kernel Mailing List Subject: RE: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP Thread-Topic: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP Thread-Index: AQHXrlppUXtiT4Ul9UCq0y1lpkQn1quyuuKAgAWuhwCAAKRkgIAAyOqAgAB9aAD//53xAIAAfQEA//+wWACAAICAgP//j4cAAA9QjQAADVLnoP//o0IAgABnfsA= Date: Wed, 29 Sep 2021 02:11:07 +0000 Message-ID: <2db5b44102264632a571e0b6ce11ef81@intel.com> References: <035290e6-d914-a113-ea6c-e845d71069cf@intel.com> <3f97b77e-a609-997b-3be7-f44ff7312b0d@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 x-originating-ip: [10.1.200.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > But the helpers seem to be generic. They take "task" as a parameter and > handle the task as non-current case. So the helpers are not for PASID only. > They may be used by others to modify a running task's FPU state. But > It's not safe to do so. > > At least need some comments/restriction for the helpers to be used on > a running task? Fenghua, Correct. When I add some comments I'll make it very clear that it is the responsibility of the caller to make sure that the task that is targeted cannot run. Earlier in this thread Dave suggested there are two cases where these helpers might be useful: 1) Fork/clone - to set up some xsave state in the child ... but this would be done before the child is allowed to run. 2) ptrace - this is a "maybe" because ptrace already has code to handle all the xsave state as a single entity. Perhaps someone might want to change it to only modify a single feature ... but this seems unlikely. In any case the ptrace code already "stops" the target process while it is reading/writing state. -Tony