Messages in this thread | | | Subject | Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP | From | Dave Hansen <> | Date | Wed, 22 Sep 2021 14:33:09 -0700 |
| |
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.
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. :)
| |