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;
User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416
Mime-Version: 1.0
Message-Id: <ef151c13-1126-43b1-ab55-4bd86fa4c2c0@www.fastmail.com>
In-Reply-To: <CAJvTdKmq2qKgkkbeQzQ6dG14+EWZ_eTbz6c6neGLFo_X=PCJeg@mail.gmail.com>
References: <20210523193259.26200-1-chang.seok.bae@intel.com>
 <20210523193259.26200-26-chang.seok.bae@intel.com>
 <6197fd94-76a9-a391-f290-7001a71add7f@kernel.org>
 <CAJvTdKmq2qKgkkbeQzQ6dG14+EWZ_eTbz6c6neGLFo_X=PCJeg@mail.gmail.com>
Date:   Mon, 24 May 2021 21:46:06 -0700
From:   "Andy Lutomirski" <luto@kernel.org>
To:     "Len Brown" <lenb@kernel.org>
Cc:     "Bae, Chang Seok" <chang.seok.bae@intel.com>,
        "Borislav Petkov" <bp@suse.de>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        "Ingo Molnar" <mingo@kernel.org>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        "Brown, Len" <len.brown@intel.com>,
        "Dave Hansen" <dave.hansen@intel.com>,
        "Liu, Jing2" <jing2.liu@intel.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: =?UTF-8?Q?Re:_[PATCH_v5_25/28]_x86/fpu/xstate:_Skip_writing_zeros_to_sig?=
 =?UTF-8?Q?nal_frame_for_dynamic_user_states_if_in_INIT-state?=
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On Mon, May 24, 2021, at 11:15 AM, Len Brown wrote:
> On Sun, May 23, 2021 at 11:28 PM Andy Lutomirski <luto@kernel.org> wro=
te:
>=20
> > But what happens if we don't have the XGETBV1 feature?  Are we makin=
g
> > AMX support depend on XGETBV1?
>=20
> Yes, AMX systems always have XGETBV.
>=20
> > 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.
>=20
> 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.

If we ever have a task that is =E2=80=9Cnon-AMX=E2=80=9D but has non-INI=
T AMX, then either we or the hardware has seriously screwed up.

So the logic boils down to: if (a) optimize; if (b) optimize; where a im=
plies b.  I maintain my objection =E2=80=94 I think this is redundant.

>=20
> > Finally, isn't part of the point that we need to avoid even *allocat=
ing*
> > space for non-AMX-using tasks?  That would require writing out the
> > compacted format and/or fiddling with XCR0.
>=20
> 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.
>=20
> We can optimize the data transfer (and we have), but we can't optimize=
 the space
> without changing that ABI.

We are between a rock and a hard place here.  On the one hand, our ABI (=
supposedly =E2=80=94 no one seems to have really confirmed this) has the=
 signal frame in uncompacted form.  On the other hand, our ABI most defi=
nitely has signal frames under 2kB by a decent amount.

I think we should apply a simple patch to Linux to add a boot parameter =
x86_extra_signal_space=3D8192 that will pad the signal frame by 8192 byt=
es.  And then we ask people to seriously test their workloads with that =
parameter set. If things break, then AMX in its current proposed form ma=
y be off the table.

At least my dynamic XCR0 proposal has the property that legacy programs =
and AMX can reliably coexist on the same system.