[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z8iUMRGyUpgisuc_@gmail.com>
Date: Wed, 5 Mar 2025 19:13:05 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Eric Biggers <ebiggers@...nel.org>, 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
* Dave Hansen <dave.hansen@...el.com> wrote:
> On 3/5/25 09:37, Ingo Molnar wrote:
> >
> > * Dave Hansen <dave.hansen@...el.com> wrote:
> >
> >> 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.
> >
> > Yes - but my point is: with any APX build we'd probably be saving
> > FPU(-ish) registers at entry points, into a separate context area. If
> > that includes FPU registers then we'd not have to do
> > kernel_fpu_begin()/end().
>
> That's true. But wouldn't it be a bit silly to include _all_ FPU
> registers? If the kernel isn't using AVX512, why bother saving and
> restoring AVX512?
Fair enough - although I bet the execution time difference between a
partial and a full FPU context save isn't as large as the buffer size
would suggest... There's a lot of setup cost in XSAVE* instructions
last I checked.
Thanks,
Ingo
Powered by blists - more mailing lists