Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210523193259.26200-1-chang.seok.bae@intel.com>
 <20210523193259.26200-26-chang.seok.bae@intel.com> <6197fd94-76a9-a391-f290-7001a71add7f@kernel.org>
In-Reply-To: <6197fd94-76a9-a391-f290-7001a71add7f@kernel.org>
From:   Len Brown <lenb@kernel.org>
Date:   Mon, 24 May 2021 14:15:53 -0400
Message-ID: <CAJvTdKmq2qKgkkbeQzQ6dG14+EWZ_eTbz6c6neGLFo_X=PCJeg@mail.gmail.com>
Subject: Re: [PATCH v5 25/28] x86/fpu/xstate: Skip writing zeros to signal
 frame for dynamic user states if in INIT-state
To:     Andy Lutomirski <luto@kernel.org>
Cc:     "Chang S. Bae" <chang.seok.bae@intel.com>,
        Borislav Petkov <bp@suse.de>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@kernel.org>, X86 ML <x86@kernel.org>,
        "Brown, Len" <len.brown@intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        "Liu, Jing2" <jing2.liu@intel.com>,
        "Ravi V. Shankar" <ravi.v.shankar@intel.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, May 23, 2021 at 11:28 PM Andy Lutomirski <luto@kernel.org> wrote:

> But what happens if we don't have the XGETBV1 feature?  Are we making
> AMX support depend on XGETBV1?

Yes, AMX systems always have XGETBV.

> How does this patch interact with "[PATCH v5 24/28] x86/fpu/xstate: Use
> per-task xstate mask for saving xstate in signal frame"?  They seem to
> be try to do something similar but not quite the same, and they seem to
> be patching the same function.  The result seems odd.

The previous patch allowed non-AMX tasks to skip writing 8KB of zeros
to their signal stack.  This patch builds on that to allow an AMX-task
in INIT to also skip writing 8KB of zeros to its signal stack.

> Finally, isn't part of the point that we need to avoid even *allocating*
> space for non-AMX-using tasks?  That would require writing out the
> compacted format and/or fiddling with XCR0.

The current signal stack ABI is that the user receives all
architectural state in
uncompressed XTATE format on the signal stack.  They can XRESTOR it
and the right thing happens.

We can optimize the data transfer (and we have), but we can't optimize the space
without changing that ABI.

Again, I'm happy to investigate a new opt-in fast-signal ABI that doesn't
have all this state.  But so far, nobody has asked for it, or even identified
an application that cares about minimum-overhead signals.
Can you recommend one?

thanks,
Len Brown, Intel Open Source Technology Center