Messages in this thread | | | Date | Thu, 23 Sep 2021 09:05:00 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP |
| |
On Wed, Sep 22, 2021 at 02:33:09PM -0700, Dave Hansen wrote: > On 9/22/21 2:11 PM, Peter Zijlstra 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? > > To reiterate: on systems with no X86_FEATURE_ENQCMD, there is basically > no additional overhead. It isn't worth doing decoding there.
Well, they won't get past the X86_FEATURE check anyway, so who cares.
> On systems with X86_FEATURE_ENQCMD, but where it is unused, the #GP > handler gets some new overhead on every #GP. Basically: > > > + pasid = current->mm->pasid; > > + if (pasid == PASID_DISABLED) > > + return false; > > That's still pretty cheap. Probably not worth doing decoding there either. > > So, that leaves us with if you are: > 1. On system with X86_FEATURE_ENQCMD > 2. In a process/mm that has an allocated pasid > 3. Your *task* does not have the MSR set > 4. You get a #GP for some other reason > > Then, you'll do this double-#GP dance. > > So, instruction decoding could absolutely be added between steps 3 and > 4. It would absolutely save doing the double-#GP in cases where 1/2/3 > are met. But, I wouldn't move it up above and of the 1/2/3 checks > because they're way cheaper than instruction decoding. > > In the end, it didn't seem worth it to me to be optimizing a relatively > rare path which 99% of the time ends up in a crash. > > If you want instruction decoding in here, though, just say the word. :)
Instruction deoding makes it obvious you only consume your own #GP, the alternative is a comment that explains this reasoning. Having neither gets you confusion as per this thread.
| |