Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP

From: Peter Zijlstra
Date: Wed Sep 29 2021 - 05:00:51 EST


On Fri, Sep 24, 2021 at 08:39:24AM -0700, Luck, Tony wrote:

> If you have ctags installed then a ctrl-] on that
> __fixup_pasid_exception() will take you to the function with
> the comments. No electron microscope needed.

I to use ctags, but when reading the #GP handler, this is a whole
different file. Also, I don't find any of those comments explaining the
not-our-#GP-but-harmless-cycle issue.

The current->has_valid_pasid one comes close, but just misses it. But
really the place to put this is in the #GP handler itself so we don't
have to dig through every call there to figure out how it's supposed to
work.

> +
> +/*
> + * Try to figure out if there is a PASID MSR value to propagate to the
> + * thread taking the #GP.
> + */
> +bool __fixup_pasid_exception(void)
> +{
> + u32 pasid;
> +
> + /*
> + * This function is called only when this #GP was triggered from user
> + * space. So the mm cannot be NULL.
> + */
> + pasid = current->mm->pasid;
> +
> + /* If no PASID is allocated, there is nothing to propagate. */
> + if (pasid == PASID_DISABLED)
> + return false;
> +
> + /*
> + * If the current task already has a valid PASID MSR, then the #GP
> + * fault must be for some non-ENQCMD related reason.
> + */
> + if (current->has_valid_pasid)
> + return false;
> +
> + /* Fix up the MSR by the PASID in the mm. */
> + fpu__pasid_write(pasid);
> + current->has_valid_pasid = 1;
> +
> + return true;
> +}
>
> -Tony