From: Borislav Petkov <bp@alien8.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Matt Fleming <matt.fleming@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-tip-commits@vger.kernel.org"
<linux-tip-commits@vger.kernel.org>
Subject: Re: [tip:x86/efi] x86/efi: Check for unsafe dealing with FPU state in irq ctxt
Date: Thu, 5 Jun 2014 18:37:11 +0200 [thread overview]
Message-ID: <20140605163711.GG16642@pd.tnic> (raw)
In-Reply-To: <53909B50.50407@zytor.com>
On Thu, Jun 05, 2014 at 09:31:12AM -0700, H. Peter Anvin wrote:
> The bottom line is that we can't call EFI from a context where we can't
> use the FPU. Or specifically, we can't then resume execution.
Can't we allocate a save-state area, stash the state there and let EFI
scribble over it? When EFI returns, we scribble over it back assuming it
has done the saving/restoring on its own.
> If all we're doing is stashing away some data before dying, well,
> then, by all means - but we need to make sure that is what actually
> happens.
Yeah, who knows, we might return. I'm thinking of a #MC here which is
serious enough to real exception, we do some handling and issue the
error info into pstore and continue execution. Purely hypothetical
though.
> As far adding additional xstate save areas, the current size of the
> xstate is about ~2.5K for AVX-512 enabled processors, and we need one
> per thread. If we make that two copies, then
> kernel_fpu_begin()..._end() would no longer have to disable preemption,
> but it wouldn't resolve the conflict about using the FPU from IRQ
> context when inside kernel_fpu_begin().._end().
>
> To support the FPU in IRQ context we end up having to create a percpu
> FPU state stack, and it becomes then a matter of how deep that stack
> would have to be.
... if it all makes sense at all, of course.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2014-06-05 16:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <tip-baa916f39b50ad91661534652110df40396acda0@git.kernel.org>
2014-06-04 22:17 ` [tip:x86/efi] x86/efi: Check for unsafe dealing with FPU state in irq ctxt H. Peter Anvin
2014-06-04 22:49 ` Borislav Petkov
2014-06-04 22:52 ` H. Peter Anvin
2014-06-05 0:19 ` Andy Lutomirski
2014-06-05 7:18 ` Borislav Petkov
2014-06-05 8:49 ` Matt Fleming
2014-06-05 9:02 ` Borislav Petkov
2014-06-05 15:44 ` Andy Lutomirski
2014-06-05 15:53 ` Borislav Petkov
2014-06-05 16:01 ` Andy Lutomirski
2014-06-05 16:08 ` Borislav Petkov
2014-06-05 16:14 ` Andy Lutomirski
2014-06-05 16:18 ` Borislav Petkov
2014-06-05 16:31 ` H. Peter Anvin
2014-06-05 16:35 ` Andy Lutomirski
2014-06-05 16:43 ` H. Peter Anvin
2014-06-05 16:37 ` Borislav Petkov [this message]
2014-06-05 16:43 ` H. Peter Anvin
2014-06-05 16:44 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140605163711.GG16642@pd.tnic \
--to=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=matt.fleming@intel.com \
--cc=mingo@kernel.org \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.