On Sat, 16 Jan 2021 at 06:13, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 1/15/21 6:04 PM, Eric Biggers wrote: > > On Fri, Jan 15, 2021 at 04:20:44PM -0800, Dave Hansen wrote: > >> On 1/15/21 4:14 PM, Dey, Megha wrote: > >>> Also, I do not know of any cores that implement PCLMULQDQ and not AES-NI. > >> That's true, bit it's also possible that a hypervisor could enumerate > >> support for PCLMULQDQ and not AES-NI. In general, we've tried to > >> implement x86 CPU features independently, even if they never show up in > >> a real CPU independently. > > We only add optimized implementations of crypto algorithms if they are actually > > useful, though. If they would never be used in practice, that's not useful. > > Yes, totally agree. If it's not of practical use, it doesn't get merged. > > I just wanted to share what we do for other related but independent CPU > features. Thanks for the insight. The issue with the current GHASH driver is that it uses infrastructure that we may decide to remove (the async cryptd helper [0]). So adding more dependencies on that without any proven benefit should obviously be avoided at this time as well. [0] https://lore.kernel.org/linux-arm-kernel/20201218170106.23280-1-ardb@xxxxxxxxxx/
