Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Elliott, Robert (Servers)" <elliott@hpe.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>,
        Ard Biesheuvel <ardb@kernel.org>
CC:     "Jason A. Donenfeld" <Jason@zx2c4.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "tim.c.chen@linux.intel.com" <tim.c.chen@linux.intel.com>,
        "ap420073@gmail.com" <ap420073@gmail.com>,
        "David.Laight@aculab.com" <David.Laight@aculab.com>,
        "ebiggers@kernel.org" <ebiggers@kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 10/24] crypto: x86/poly - limit FPU preemption
Thread-Topic: [PATCH v4 10/24] crypto: x86/poly - limit FPU preemption
Thread-Index: AQHY+XHqfLLvXNGxcESumjNg7U4Mn65BZh+AgA36OwCAAAUngIAAAQwAgADfYdk=
Date:   Mon, 28 Nov 2022 16:57:19 +0000
Message-ID: <MW5PR84MB1842E182C47F77FE8C8E755BAB139@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>
References: <20221103042740.6556-1-elliott@hpe.com>
 <20221116041342.3841-1-elliott@hpe.com>
 <20221116041342.3841-11-elliott@hpe.com> <Y3TF7/+DejcnN0eV@zx2c4.com>
 <Y4B/kjS0lgzdUJHG@gondor.apana.org.au>
 <CAMj1kXHHm+L=qE5opDXhjoWZt+1eKXFeGVS=OdvyF0VNFZivCA@mail.gmail.com>
 <Y4CExnFX46mk4/1+@gondor.apana.org.au>
In-Reply-To: <Y4CExnFX46mk4/1+@gondor.apana.org.au>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?LrwP+9P/4ZyeogOf5Eha8cYZ15QU+w25rw/lI6DK787Z2QtLxSD83+R3ruAF?=
 =?us-ascii?Q?eXdJ5Z+FCf7EhKZtXqyvaBKC66tB75P+w7PVmvTR4tETuI48jRi8Moy68f4j?=
 =?us-ascii?Q?STqNSbw6wnlIgTGVLthRq2mpIRnh9nNJRhYzOJ3RsiiFGTRcxnZBaQ4aIByb?=
 =?us-ascii?Q?SuZSLMsHzsyitFEK7z7gT0/rN/hyR3BKFWpR4qkxlH8sEEFGLwvbUbqrjt/2?=
 =?us-ascii?Q?JUieicdj5zopuFW/D9h8Y6iGfYkbG7voZU2prHhfrdwAFu7P3IgX3/1Ot0d/?=
 =?us-ascii?Q?tbJW4qVg21H/jO7clWiDpbrt3JIXLfCjrGELLq7BfUTe4prLjKq4fXbJca6p?=
 =?us-ascii?Q?NGaEeze3DZYWZIpGIyk9/dfHgWQIAa3us9BLsbhThPu1HvOYoPVetnXE0AU4?=
 =?us-ascii?Q?A7p2H+DJ/7F7dslQi9N/yyhurZlYXutq+/C/EEftrXAu9ltVMikHg6wm7zU/?=
 =?us-ascii?Q?lSy7F2fMMlxys24cW1qopAVQsAKgKnNxa9gzuLziq3D/DrK5S/0Uwg+/jgQ4?=
 =?us-ascii?Q?p42gxWqeTTZI8ZUjU0gqYlrR0Lo50ZvVKW9gGLyAmsOsMF5wdjIGsVLZS6TL?=
 =?us-ascii?Q?a4LlZ/ZKENujzZqc5cWkJ9COrNMbuiPmC0JBc2bE/y0hT5ZpC1xWPbEZ+wk0?=
 =?us-ascii?Q?IstuQ3OmyaV/MGQxPMgoy4J0eZjf4rRXbf91i3QjUv5VechztB/zGVbkg3z9?=
 =?us-ascii?Q?A8So0+Bx30q3ttj6iKLEhxSb3NbfmDh6/nSGS6MrEfh71Jb7fqUC8cSb7aNU?=
 =?us-ascii?Q?Jsc3LfdT/frZJ7LYRoBfT6IISHZyhkfQ9ERoiroYS0cGzqLP/Vit3LsRZwQ6?=
 =?us-ascii?Q?4BpxYzohjeWedo8/U3hRH4NyRoZlhSHTIxUG3uQkO5o9TN5cNdqd158z5BCC?=
 =?us-ascii?Q?vi9I+CcDntduPfkm/QdeMtDziSXmuaKf3YpYlTpAxXUUaLzycu+LLq9TWyY4?=
 =?us-ascii?Q?x+OW2TbsPn66kKdgOGWW70UvbRu9o64MCXHGUW7NybJ3LMg15zKcj6aY3cmx?=
 =?us-ascii?Q?Bngg/tL43qZg7rR9o/jrgUIcrLHWc28VStEfvUZcvszGnBldc7yBuCO00o8G?=
 =?us-ascii?Q?KxugP4r1UmeK86CJS3XEF/H2NtKwM7R1jB68MhyyqLasr+6L24N43NLsoajw?=
 =?us-ascii?Q?YvUx+Na9Is3mSGkpHn/6J07cu0GDzyra+ucDs4UzvnRpvj/dEJHVZtPkmUtc?=
 =?us-ascii?Q?BpgkhxC2biEmY8yrpq8SxZphpXtb13FDJMlWYTj3S5fyijf9PeondKZG++W1?=
 =?us-ascii?Q?T8Q8g2tT4U/1exZpMJbQ+6aVQAFX5FeLrWtdBX/YgRX2BD/OCfXCMDBdUTHV?=
 =?us-ascii?Q?eC5hKJi+MOwaqV7WOgFahv8MrRZv6UH82VIjQRNo/IwQ8QvpSV/h0LraPDQo?=
 =?us-ascii?Q?vZ+EpyctSbvasXO82UGL/7/rRSRnuciENi+JJNwD0q2Tvc/DmokB7kK9JOfF?=
 =?us-ascii?Q?zYJQPrUkpWD9RJLqT0M59DBM2MHdga7da4orW6UTEbBogoJ0wQfIR62KoIgJ?=
 =?us-ascii?Q?Fc8CsfBASG76zlsQEAhXyFyx2itth9/YNuoJOBWxDYOdJM8fpPOdBTu8ACka?=
 =?us-ascii?Q?5Ainskbp+RqwjZn6sEw=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: d96abbb4-9d86-4be3-ed7d-08dad1619c5f
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2022 16:57:19.1599
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kapwlUOMdFvgV37uxn07wGrDnhWo/S4bjDt8MGfaeBPaMwt4nN+KuTgi288HJIuw
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR84MB1810
X-OriginatorOrg: hpe.com
X-Proofpoint-ORIG-GUID: eSFy8vhXeCa6zYoqejnMm7vEz4uodLIq
X-Proofpoint-GUID: eSFy8vhXeCa6zYoqejnMm7vEz4uodLIq
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-11-28_15,2022-11-28_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 spamscore=0
 clxscore=1015 lowpriorityscore=0 suspectscore=0 mlxscore=0 phishscore=0
 priorityscore=1501 impostorscore=0 mlxlogscore=999 malwarescore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2211280125
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


On Fri, Nov 25, 2022 at 09:59:17AM +0100, Ard Biesheuvel wrote:
> On arm64, this is implemented in an assembler macro 'cond_yield' so we
> don't need to preserve/restore the SIMD state state at all if the
> yield is not going to result in a call to schedule(). For example, the
> SHA3 code keeps 400 bytes of state in registers, which we don't want
> to save and reload unless needed. (5f6cb2e617681 'crypto:
> arm64/sha512-ce - simplify NEON yield')

That sounds like the optimal approach. There is a cost to unnecessary
kernel_fpu_begin()/end() calls - increasing their usage in the x86
sha512 driver added 929 us during one boot. The cond_yield check is
just a few memory reads and conditional branches.

I see that is built on the asm-offsets.c technique mentioned by
Dave Hansen in the x86 aria driver thread.

> Note that it is only used in shash implementations, given that they
> are the only ones that may receive unbounded inputs.

Although typical usage probably doesn't stress this, the length of the
additional associated data presented to aead implementations is
unconstrained as well. At least in x86, they can end up processing
multiple megabytes in one chunk like the hash functions (if the
associated data is a big buffer described by a sg list created
with sg_init_one()).