Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Dave Hansen <dave.hansen@intel.com>,
        LKML <linux-kernel@vger.kernel.org>
Cc:     x86@kernel.org, Andrew Cooper <andrew.cooper3@citrix.com>,
        "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Subject: Re: [patch 2/3] x86/fpu/xsave: Prepare for optimized compaction
In-Reply-To: <d2f927c9-187a-906c-e1f3-33541b3b5a84@intel.com>
References: <20220404103741.809025935@linutronix.de>
 <20220404104820.656881574@linutronix.de>
 <d2f927c9-187a-906c-e1f3-33541b3b5a84@intel.com>
Date:   Tue, 19 Apr 2022 14:39:36 +0200
Message-ID: <87k0bl9rhz.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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