Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp11313pxb; Wed, 22 Sep 2021 14:41:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtHCsLkT2Vnu4D44DvRPoPoDtTa45Sw/eD2BG9o74hp6wbTBIvX70YNze+yzo68ys1hSOl X-Received: by 2002:a17:906:5f96:: with SMTP id a22mr1598081eju.58.1632346864182; Wed, 22 Sep 2021 14:41:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632346864; cv=none; d=google.com; s=arc-20160816; b=0RXssQrerT75NfLMKWk2b4B4GL9aAvuupDo/bIpRkZolZCTPTyfnA84FHtHO2IunJH 88Pe+gqS3YM0kfHLAV2IDrDhMY69Ds8hIkbNTXdHU4Ug3o+Y+k3s5iFpRSD4qogwaZ15 kI+AT9g817vDkBbUp/mMHBH9JsoCWeWp6S6Z01dWXm1ZTTaIJDr82xyG4pj8SUHGVXw8 bNIIVWsrlQ+ZPXopLATQj5BFjd7Md7lHkA5jBE5e3hwyMkSnEqwjub3LzSg4h1J28hBY lVp4iSvZXnSiVn6/km4g7MCstKcK4SByEpSmFGIOODKmQKvGhS/SuJNWKtWPWe0Yd3TV R17A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Srvz5eswfkH/v4dCI05hK95BzZ9bXG9M2NDQkjUwdXc=; b=TTPKmXczClQW9y9rmirTQhiF/Z6a75hixSqod8/Qp3vG0bV+qF19u0AfnrDIcn4Isb Lc6o0Sq7bLyx74AKl78gyyhXTfZxslnLQNe8SzQ/BR5luBIXBzWshci8+I1kVWKZq4IX vSRDLwz/TzaOZgDHmrknucRBZ7etGRxPY+7k1IZJM98Hvt4qugRlCHEKHxyYhRW4mxsi GaYazFy4jr5VNydHle3q39OXlKJ6vNr4LD9K7PPis4hM52P+/Tgr4Erlx4lvWiS0V42y 2+3Xzrr8RbX/JiA6zCNHrHVx167jzrN5HDulMdOJW+2HZW5Efxme0YzfFjYKZqWDAi9y STJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 24si3752842ejg.618.2021.09.22.14.40.40; Wed, 22 Sep 2021 14:41:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238086AbhIVViA (ORCPT + 99 others); Wed, 22 Sep 2021 17:38:00 -0400 Received: from mga01.intel.com ([192.55.52.88]:4683 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238033AbhIVVh7 (ORCPT ); Wed, 22 Sep 2021 17:37:59 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10115"; a="246150924" X-IronPort-AV: E=Sophos;i="5.85,315,1624345200"; d="scan'208";a="246150924" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2021 14:36:28 -0700 X-IronPort-AV: E=Sophos;i="5.85,315,1624345200"; d="scan'208";a="557641969" Received: from otcwcpicx3.sc.intel.com ([172.25.55.73]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2021 14:36:28 -0700 Date: Wed, 22 Sep 2021 21:36:22 +0000 From: Fenghua Yu To: Peter Zijlstra Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Dave Hansen , Tony Luck , Lu Baolu , Joerg Roedel , Josh Poimboeuf , Dave Jiang , Jacob Jun Pan , Ashok Raj , Ravi V Shankar , iommu@lists.linux-foundation.org, x86 , linux-kernel Subject: Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210922211145.GF5106@worktop.programming.kicks-ass.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Peter, On Wed, Sep 22, 2021 at 11:11:45PM +0200, Peter Zijlstra wrote: > On Wed, Sep 22, 2021 at 11:07:22PM +0200, Peter Zijlstra wrote: > > On Mon, Sep 20, 2021 at 07:23:45PM +0000, Fenghua Yu wrote: > > > +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? There were comments on a previous version when we used #GP fixup method: https://lore.kernel.org/linux-iommu/f6d34d59-e6eb-ee9f-d247-8fb2f0e37549@intel.com/ There are three reasons for not decoding the instruction: 1. Parsing the instruction sets bad architectural precedent and is ugly. 2. The instruction could be modified (e.g. JVM) while decoding the instruction. It's. 3. Decoding is more complex than this patch and doesn't worth it. Thanks. -Fenghua