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.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
