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 3753CC433F5 for ; Wed, 22 Sep 2021 21:26:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0B5FA6115A for ; Wed, 22 Sep 2021 21:26:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238023AbhIVV1p convert rfc822-to-8bit (ORCPT ); Wed, 22 Sep 2021 17:27:45 -0400 Received: from mga17.intel.com ([192.55.52.151]:18706 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237802AbhIVV1n (ORCPT ); Wed, 22 Sep 2021 17:27:43 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10115"; a="203859611" X-IronPort-AV: E=Sophos;i="5.85,315,1624345200"; d="scan'208";a="203859611" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2021 14:26:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,315,1624345200"; d="scan'208";a="435587347" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by orsmga006.jf.intel.com with ESMTP; 22 Sep 2021 14:26:11 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Wed, 22 Sep 2021 14:26:10 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Wed, 22 Sep 2021 14:26:10 -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; Wed, 22 Sep 2021 14:26:10 -0700 From: "Luck, Tony" To: Peter Zijlstra , "Yu, Fenghua" CC: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Andy Lutomirski , "Hansen, Dave" , Lu Baolu , "Joerg Roedel" , Josh Poimboeuf , "Jiang, Dave" , "Pan, Jacob jun" , "Raj, Ashok" , "Shankar, Ravi V" , "iommu@lists.linux-foundation.org" , x86 , linux-kernel 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: AQHXrlppUXtiT4Ul9UCq0y1lpkQn1quxBE8AgAABOoD//4u5UA== Date: Wed, 22 Sep 2021 21:26:10 +0000 Message-ID: References: <20210920192349.2602141-1-fenghua.yu@intel.com> <20210920192349.2602141-5-fenghua.yu@intel.com> <20210922210722.GV4323@worktop.programming.kicks-ass.net> <20210922211145.GF5106@worktop.programming.kicks-ass.net> In-Reply-To: <20210922211145.GF5106@worktop.programming.kicks-ass.net> 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 >> > +static bool fixup_pasid_exception(void) >> > +{ >> > + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD)) >> > + return false; >> > + >> > + return __fixup_pasid_exception(); >> > +} > > That is, shouldn't the above at the very least decode the instruction > causing the #GP and check it's this ENQCMD thing? It can't reliably do that because some other thread in the process may have re-written the memory that regs->ip points at (bizarre case, but I think Dave Hansen brought it up). So it would just add extra code, and still only be a hint. Without the check this sequence is possible: 1) Process binds an accelerator (so mm->pasid is set) 2) Task in the process executes something other than ENQCMD that gets a #GP 3) Kernel says "Oh, mm->pasid is set, I'll initialize the IA32_PASID MSR to see if that fixes it" 4) Nope. Re-executing the instruction at step #2 just gives another #GP 5) Kernel says "I already set IA32_PASID, so this must be something else ... do regular #GP actions" Now if the task catches the signal that results from step #5 and avoids termination, it will have IA32_PASID set ... but to the right value should it go on to actually execute ENQCMD at some future point. So the corner case from not knowing whether this #GP was from ENQCMD or not is harmless. -Tony 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 B4451C433EF for ; Wed, 22 Sep 2021 21:26:29 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 71BF96115A for ; Wed, 22 Sep 2021 21:26:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 71BF96115A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 42CB784052; Wed, 22 Sep 2021 21:26:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnFS6baiW8vV; Wed, 22 Sep 2021 21:26:28 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp1.osuosl.org (Postfix) with ESMTPS id F12B08404E; Wed, 22 Sep 2021 21:26:27 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id C8A61C000F; Wed, 22 Sep 2021 21:26:27 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id E8539C000D for ; Wed, 22 Sep 2021 21:26:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id CA74D40794 for ; Wed, 22 Sep 2021 21:26:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwi4KnToK0SE for ; Wed, 22 Sep 2021 21:26:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by smtp4.osuosl.org (Postfix) with ESMTPS id 202A740704 for ; Wed, 22 Sep 2021 21:26:26 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10115"; a="246148892" X-IronPort-AV: E=Sophos;i="5.85,315,1624345200"; d="scan'208";a="246148892" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2021 14:26:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,315,1624345200"; d="scan'208";a="435587347" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by orsmga006.jf.intel.com with ESMTP; 22 Sep 2021 14:26:11 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Wed, 22 Sep 2021 14:26:10 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Wed, 22 Sep 2021 14:26:10 -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; Wed, 22 Sep 2021 14:26:10 -0700 From: "Luck, Tony" To: Peter Zijlstra , "Yu, Fenghua" 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: AQHXrlppUXtiT4Ul9UCq0y1lpkQn1quxBE8AgAABOoD//4u5UA== Date: Wed, 22 Sep 2021 21:26:10 +0000 Message-ID: References: <20210920192349.2602141-1-fenghua.yu@intel.com> <20210920192349.2602141-5-fenghua.yu@intel.com> <20210922210722.GV4323@worktop.programming.kicks-ass.net> <20210922211145.GF5106@worktop.programming.kicks-ass.net> In-Reply-To: <20210922211145.GF5106@worktop.programming.kicks-ass.net> 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] MIME-Version: 1.0 Cc: "Shankar, Ravi V" , "Jiang, Dave" , "Raj, Ashok" , x86 , linux-kernel , "Hansen, Dave" , "iommu@lists.linux-foundation.org" , Ingo Molnar , Borislav Petkov , "Pan, Jacob jun" , Andy Lutomirski , Josh Poimboeuf , Thomas Gleixner X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" >> > +static bool fixup_pasid_exception(void) >> > +{ >> > + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD)) >> > + return false; >> > + >> > + return __fixup_pasid_exception(); >> > +} > > That is, shouldn't the above at the very least decode the instruction > causing the #GP and check it's this ENQCMD thing? It can't reliably do that because some other thread in the process may have re-written the memory that regs->ip points at (bizarre case, but I think Dave Hansen brought it up). So it would just add extra code, and still only be a hint. Without the check this sequence is possible: 1) Process binds an accelerator (so mm->pasid is set) 2) Task in the process executes something other than ENQCMD that gets a #GP 3) Kernel says "Oh, mm->pasid is set, I'll initialize the IA32_PASID MSR to see if that fixes it" 4) Nope. Re-executing the instruction at step #2 just gives another #GP 5) Kernel says "I already set IA32_PASID, so this must be something else ... do regular #GP actions" Now if the task catches the signal that results from step #5 and avoids termination, it will have IA32_PASID set ... but to the right value should it go on to actually execute ENQCMD at some future point. So the corner case from not knowing whether this #GP was from ENQCMD or not is harmless. -Tony _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu