Re: [patch 2/3] x86/fpu/xsave: Prepare for optimized compaction
From: Thomas Gleixner
Date: Tue Apr 19 2022 - 09:04:17 EST
On Thu, Apr 14 2022 at 08:46, Dave Hansen wrote:
> On 4/4/22 05:11, Thomas Gleixner wrote:
> Any interest in doing something like the attached to make
> copy_uabi_to_xstate() easier to read?
Yeah. I've picked it up.
>> +static void xsave_adjust_xcomp(struct fpstate *fpstate, u64 xuser)
>> +{
>> + struct xregs_state *xsave = &fpstate->regs.xsave;
>> + u64 xtmp, xall, xbv, xcur = xsave->header.xfeatures;
>> + int i;
>> +
>> + /* Nothing to do if optimized compaction is not in use */
>> + if (!xsave_use_xgetbv1())
>> + return;
>
> The comment makes me wonder if we need a more descriptive name for
> xsave_use_xgetbv1(), like:
>
> if (!xsave_do_optimized_compaction())
> return;
Makes sense.
>> + /*
>> + * No more optimizations. Set the user features and move the
>> + * supervisor state(s). If the new user feature is past
>> + * the supervisor state, then the loop is moving nothing.
>> + */
>> + xtmp = xbv & XFEATURE_MASK_SUPERVISOR_ALL;
>> + xall = xbv | xuser;
>
>
> I'd probably at least comment why the loop is backwards:
>
> /*
> * Features are only be moved up in the buffer. Start with
> * high features to avoid overwriting them with a lower ones.
> */
>
> I know this is a very typical way to implement non-destructive moves,
> but my stupid brain seems to default to assuming that for loops only go
> forward.
:)
>> + for (i = fls64(xtmp) - 1; i >= FIRST_EXTENDED_XFEATURE;
>> + i = fls64(xtmp) - 1) {
>> + unsigned int to, from;
>
> Is it worth a check here like:
>
> /* Do not move features in their init state: */
> if (!(xcur & BIT_ULL(i))) {
> xtmp &= ~BIT_ULL(i);
> continue;
> }
That would also require to clear the bit in xall, but we can't do that
in the loop as that affects offsets. Let me think about that.
Thanks,
tglx