From: Dave Hansen <dave.hansen@intel.com> To: "Luck, Tony" <tony.luck@intel.com>, Peter Zijlstra <peterz@infradead.org> Cc: Fenghua Yu <fenghua.yu@intel.com>, Thomas Gleixner <tglx@linutronix.de>, Joerg Roedel <joro@8bytes.org>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, H Peter Anvin <hpa@zytor.com>, David Woodhouse <dwmw2@infradead.org>, Lu Baolu <baolu.lu@linux.intel.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, Christoph Hellwig <hch@infradeed.org>, Ashok Raj <ashok.raj@intel.com>, Jacob Jun Pan <jacob.jun.pan@intel.com>, Dave Jiang <dave.jiang@intel.com>, Sohil Mehta <sohil.mehta@intel.com>, Ravi V Shankar <ravi.v.shankar@intel.com>, linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>, iommu@lists.linux-foundation.org Subject: Re: [PATCH v4 12/12] x86/traps: Fix up invalid PASID Date: Fri, 26 Jun 2020 11:23:12 -0700 [thread overview] Message-ID: <aa3d7b7c-d6aa-06b4-30f7-0e90af50a1f3@intel.com> (raw) In-Reply-To: <20200626181000.GA22833@agluck-desk2.amr.corp.intel.com> On 6/26/20 11:10 AM, Luck, Tony wrote: > On Fri, Jun 26, 2020 at 11:44:50AM +0200, Peter Zijlstra wrote: >> On Thu, Jun 25, 2020 at 01:17:22PM -0700, Fenghua Yu wrote: >> >>> +static bool fixup_pasid_exception(void) >>> +{ >>> + if (!IS_ENABLED(CONFIG_INTEL_IOMMU_SVM)) >>> + return false; >>> + if (!static_cpu_has(X86_FEATURE_ENQCMD)) >>> + return false; >> >> elsewhere you had another variation: >> >> + if (!IS_ENABLED(CONFIG_INTEL_IOMMU_SVM)) >> + return; >> + >> + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD)) >> + return; >> >> Which is it, and why do we need the CONFIG thing when combined with the >> enabled thing? > > Do we have a standard way of coding for a feature that depends on multiple > other features? For this case the system needs to both suport the ENQCMD > instruction, and also have kernel code that programs the IOMMU. Not really a standard one. We could setup_clear_cpu_cap(X86_FEATURE_ENQCMD) during boot if we see that CONFIG_INTEL_IOMMU_SVM=n or if we don't have a detected IOMMU. That would at least get static value patching which would make some of the feature checks very cheap. That means we can't use ENQCMD at all in the kernel, though. Is that an issue? Is the CPU feature truly dependent on IOMMU_SVM? > And/or guidance on when to use each of the very somewhat simlar looking > boot_cpu_has() > static_cpu_has() > IS_ENABLED() > cpu_feature_enabled(X86_FEATURE_ENQCMD) > options? cpu_feature_enabled() is by go-to for checking X86_FEATUREs. It has compile-time checking along with static checking. If you use cpu_feature_enabled(), and we added: #ifdef CONFIG_INTEL_IOMMU_SVM # define DISABLE_ENQCMD 0 #else # define DISABLE_ENQCMD (1 << (X86_FEATURE_ENQCMD & <bitval>)) #endif to arch/x86/include/asm/disabled-features.h, then we could check only X86_FEATURE_ENQCMD, and we'd get that IS_ENABLED() check for "free".
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@intel.com> To: "Luck, Tony" <tony.luck@intel.com>, Peter Zijlstra <peterz@infradead.org> Cc: Fenghua Yu <fenghua.yu@intel.com>, Dave Jiang <dave.jiang@intel.com>, Ashok Raj <ashok.raj@intel.com>, Ravi V Shankar <ravi.v.shankar@intel.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, x86 <x86@kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, iommu@lists.linux-foundation.org, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Jacob Jun Pan <jacob.jun.pan@intel.com>, H Peter Anvin <hpa@zytor.com>, Christoph Hellwig <hch@infradeed.org>, Thomas Gleixner <tglx@linutronix.de>, David Woodhouse <dwmw2@infradead.org> Subject: Re: [PATCH v4 12/12] x86/traps: Fix up invalid PASID Date: Fri, 26 Jun 2020 11:23:12 -0700 [thread overview] Message-ID: <aa3d7b7c-d6aa-06b4-30f7-0e90af50a1f3@intel.com> (raw) In-Reply-To: <20200626181000.GA22833@agluck-desk2.amr.corp.intel.com> On 6/26/20 11:10 AM, Luck, Tony wrote: > On Fri, Jun 26, 2020 at 11:44:50AM +0200, Peter Zijlstra wrote: >> On Thu, Jun 25, 2020 at 01:17:22PM -0700, Fenghua Yu wrote: >> >>> +static bool fixup_pasid_exception(void) >>> +{ >>> + if (!IS_ENABLED(CONFIG_INTEL_IOMMU_SVM)) >>> + return false; >>> + if (!static_cpu_has(X86_FEATURE_ENQCMD)) >>> + return false; >> >> elsewhere you had another variation: >> >> + if (!IS_ENABLED(CONFIG_INTEL_IOMMU_SVM)) >> + return; >> + >> + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD)) >> + return; >> >> Which is it, and why do we need the CONFIG thing when combined with the >> enabled thing? > > Do we have a standard way of coding for a feature that depends on multiple > other features? For this case the system needs to both suport the ENQCMD > instruction, and also have kernel code that programs the IOMMU. Not really a standard one. We could setup_clear_cpu_cap(X86_FEATURE_ENQCMD) during boot if we see that CONFIG_INTEL_IOMMU_SVM=n or if we don't have a detected IOMMU. That would at least get static value patching which would make some of the feature checks very cheap. That means we can't use ENQCMD at all in the kernel, though. Is that an issue? Is the CPU feature truly dependent on IOMMU_SVM? > And/or guidance on when to use each of the very somewhat simlar looking > boot_cpu_has() > static_cpu_has() > IS_ENABLED() > cpu_feature_enabled(X86_FEATURE_ENQCMD) > options? cpu_feature_enabled() is by go-to for checking X86_FEATUREs. It has compile-time checking along with static checking. If you use cpu_feature_enabled(), and we added: #ifdef CONFIG_INTEL_IOMMU_SVM # define DISABLE_ENQCMD 0 #else # define DISABLE_ENQCMD (1 << (X86_FEATURE_ENQCMD & <bitval>)) #endif to arch/x86/include/asm/disabled-features.h, then we could check only X86_FEATURE_ENQCMD, and we'd get that IS_ENABLED() check for "free". _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-06-26 18:23 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-25 20:17 [PATCH v4 00/12] x86: tag application address space for devices Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-25 20:17 ` [PATCH v4 01/12] iommu: Change type of pasid to u32 Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-26 1:13 ` Lu Baolu 2020-06-26 1:13 ` Lu Baolu 2020-06-25 20:17 ` [PATCH v4 02/12] iommu/vt-d: Change flags type to unsigned int in binding mm Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-26 1:14 ` Lu Baolu 2020-06-26 1:14 ` Lu Baolu 2020-06-25 20:17 ` [PATCH v4 03/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing) Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-25 20:17 ` [PATCH v4 04/12] x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-25 20:17 ` [PATCH v4 05/12] x86/fpu/xstate: Add supervisor PASID state for ENQCMD feature Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-25 20:17 ` [PATCH v4 06/12] x86/msr-index: Define IA32_PASID MSR Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-25 20:17 ` [PATCH v4 07/12] mm: Define pasid in mm Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-25 20:17 ` [PATCH v4 08/12] fork: Clear PASID for new mm Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-25 20:17 ` [PATCH v4 09/12] x86/process: Clear PASID state for a newly forked/cloned thread Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-25 20:17 ` [PATCH v4 10/12] x86/mmu: Allocate/free PASID Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-26 1:42 ` Lu Baolu 2020-06-26 1:42 ` Lu Baolu 2020-06-25 20:17 ` [PATCH v4 11/12] sched: Define and initialize a flag to identify valid PASID in the task Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-25 20:17 ` [PATCH v4 12/12] x86/traps: Fix up invalid PASID Fenghua Yu 2020-06-25 20:17 ` Fenghua Yu 2020-06-26 1:46 ` Lu Baolu 2020-06-26 1:46 ` Lu Baolu 2020-06-26 9:44 ` Peter Zijlstra 2020-06-26 9:44 ` Peter Zijlstra 2020-06-26 18:10 ` Luck, Tony 2020-06-26 18:10 ` Luck, Tony 2020-06-26 18:15 ` Borislav Petkov 2020-06-26 18:15 ` Borislav Petkov 2020-06-26 18:23 ` Dave Hansen [this message] 2020-06-26 18:23 ` Dave Hansen 2020-06-26 18:35 ` Fenghua Yu 2020-06-26 18:35 ` Fenghua Yu 2020-06-26 18:16 ` Fenghua Yu 2020-06-26 18:16 ` Fenghua Yu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=aa3d7b7c-d6aa-06b4-30f7-0e90af50a1f3@intel.com \ --to=dave.hansen@intel.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=bp@alien8.de \ --cc=dave.jiang@intel.com \ --cc=dwmw2@infradead.org \ --cc=fenghua.yu@intel.com \ --cc=hch@infradeed.org \ --cc=hpa@zytor.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jacob.jun.pan@intel.com \ --cc=jean-philippe@linaro.org \ --cc=joro@8bytes.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=ravi.v.shankar@intel.com \ --cc=sohil.mehta@intel.com \ --cc=tglx@linutronix.de \ --cc=tony.luck@intel.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.