[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b6a80f6d-8469-429d-b03a-8fa71a33046b@intel.com>
Date: Wed, 5 Mar 2025 08:55:12 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Ingo Molnar <mingo@...nel.org>, Eric Biggers <ebiggers@...nel.org>
Cc: x86@...nel.org, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
Ben Greear <greearb@...delatech.com>, Xiao Liang <shaw.leon@...il.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>, "Jason A . Donenfeld" <Jason@...c4.com>,
"Bae, Chang Seok" <chang.seok.bae@...el.com>
Subject: Re: [RFC PATCH v2] x86/fpu: make kernel-mode FPU reliably usable in
softirqs
On 3/5/25 01:07, Ingo Molnar wrote:>> Alternatives considered:
>> - Make kernel-mode FPU sections fully preemptible. This would require
>> growing task_struct by another struct fpstate which is more than 2K.
>
> So that's something that will probably happen once the kernel is built
> using APX anyway?
I was expecting that building the kernel with APX would be very
different than a kernel_fpu_begin(). We don't just need *one* more save
area for APX registers: we need a stack, just like normal GPRs.
We'd effectively need to enlarge pt_regs and fix up things like
PUSH_AND_CLEAR_REGS to save the APX registers in addition to the good
old GPRs before calling C code.
That's what I was thinking at least. Did folks have more clever ideas?
Powered by blists - more mailing lists