From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Jordan Justen <jordan.l.justen@intel.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
Laszlo Ersek <lersek@redhat.com>,
Anthony Perard <anthony.perard@citrix.com>,
Julien Grall <julien.grall@linaro.org>
Subject: Re: [PATCH 06/10] OvmfPkg/Sec: Disable optimizations for TemporaryRamMigration
Date: Mon, 18 Feb 2019 10:32:53 +0100 [thread overview]
Message-ID: <CAKv+Gu-v2YCfg44yPJAJBzt9OhtWq2koP2HpfQ5rT_Tc+kZb1Q@mail.gmail.com> (raw)
In-Reply-To: <155048090465.22654.1079629797155553207@jljusten-skl>
On Mon, 18 Feb 2019 at 10:08, Jordan Justen <jordan.l.justen@intel.com> wrote:
>
> On 2019-02-17 23:53:01, Ard Biesheuvel wrote:
> > On Mon, 18 Feb 2019 at 05:12, Jordan Justen <jordan.l.justen@intel.com> wrote:
> > >
> >
> > This needs an explanation why optimization needs to be disabled.
>
> I'm not sure this is required. The reason I added these patches is to
> hopefully prevent the compiler from removing the frame pointer. We
> adjust the frame pointer in the code, and that is a little sketchy if
> the frame pointer isn't being used.
>
> Unfortunately, it can reasonably be argued that the
> TemporaryRamSupport PPI definition ultimately makes it unsafe to write
> the migration code in C.
>
> I tried reverting both the EmulatorPkg and OvmfPkg patches for
> disabling the optimizations, and with my setup there was no impact. I
> think there is a good change that we'd be pretty safe to just drop
> these two patches to wait and see if someone encounters a situation
> that requires it.
>
> Ok, so based on this explanation, do you think I should add info to
> the commit message and keep the patches, or just drop them?
>
I think 'little sketchy' is an understatement here (as is
setjmp/longjmp in general), but it is the reality we have to deal with
when writing startup code in C. Looking at the code, I agree that the
fact that [re]bp is assigned directly implies that we should not
permit it to be used as a general purpose register, especially when
you throw LTO into the mix, which could produce all kinds of
surprising results when it decides to inline functions being called
from here.
For GCC/Clang, I don't think it is correct to assume that changing the
optimization level will result in -fno-omit-frame-pointer to be set,
so I'd prefer setting that option directly, either via the pragma, or
for the whole file.
For MSVC, I have no idea how to tweak the compiler to force it to emit
frame pointers.
> >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
> > > Cc: Laszlo Ersek <lersek@redhat.com>
> > > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > Cc: Anthony Perard <anthony.perard@citrix.com>
> > > Cc: Julien Grall <julien.grall@linaro.org>
> > > ---
> > > OvmfPkg/Sec/SecMain.c | 12 ++++++++++++
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
> > > index 46ac739862..86c22a2ac9 100644
> > > --- a/OvmfPkg/Sec/SecMain.c
> > > +++ b/OvmfPkg/Sec/SecMain.c
> > > @@ -873,6 +873,13 @@ SecStartupPhase2(
> > > CpuDeadLoop ();
> > > }
> > >
> > > +#ifdef __GNUC__
> > > +#pragma GCC push_options
> > > +#pragma GCC optimize ("O0")
> > > +#else
> > > +#pragma optimize ("", off)
> > > +#endif
> > > +
> > > EFI_STATUS
> > > EFIAPI
> > > TemporaryRamMigration (
> > > @@ -946,3 +953,8 @@ TemporaryRamMigration (
> > > return EFI_SUCCESS;
> > > }
> > >
> > > +#ifdef __GNUC__
> > > +#pragma GCC pop_options
> > > +#else
> > > +#pragma optimize ("", on)
> > > +#endif
> >
> > I can't tell from the context if this is the end of the file, but if
> > it is not, aren't you turning on optimization here for non-GCC even if
> > it was not enabled on the command line to begin with?
next prev parent reply other threads:[~2019-02-18 9:33 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 4:11 [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration Jordan Justen
2019-02-18 4:11 ` [PATCH 01/10] EmulatorPkg/build.sh: Fix missing usage of -b BUILDTARGET parameter Jordan Justen
2019-02-18 4:11 ` [PATCH 02/10] EmulatorPkg/Unix/Host: Use PcdInitValueInTempStack to init temp-ram Jordan Justen
2019-02-18 4:11 ` [PATCH 03/10] EmulatorPkg/Sec: Replace assembly temp-ram support with C code Jordan Justen
2019-02-18 4:11 ` [PATCH 04/10] EmulatorPkg/Sec: Disable optimizations for TemporaryRamMigration function Jordan Justen
2019-02-18 4:11 ` [PATCH 05/10] OvmfPkg/Sec: Swap TemporaryRam Stack and Heap locations Jordan Justen
2019-02-18 12:58 ` Laszlo Ersek
2019-02-18 4:11 ` [PATCH 06/10] OvmfPkg/Sec: Disable optimizations for TemporaryRamMigration Jordan Justen
2019-02-18 7:53 ` Ard Biesheuvel
2019-02-18 9:08 ` Jordan Justen
2019-02-18 9:32 ` Ard Biesheuvel [this message]
2019-02-18 13:01 ` Laszlo Ersek
2019-02-19 22:50 ` Brian J. Johnson
2019-02-19 23:58 ` Jordan Justen
2019-02-20 8:52 ` Jordan Justen
2019-02-20 8:59 ` Ard Biesheuvel
2019-02-18 4:11 ` [PATCH 07/10] MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram migration Jordan Justen
2019-02-18 4:11 ` [PATCH 08/10] MdeModulePkg/Core/Pei: Use assembly for X64 TemporaryRamMigration Jordan Justen
2019-02-18 4:11 ` [PATCH 09/10] MdeModulePkg/Core/Pei: Use assembly for IA32 TemporaryRamMigration Jordan Justen
2019-02-18 4:11 ` [PATCH 10/10] OvmfPkg/Sec: Fill Temp Ram after TemporaryRamMigration Jordan Justen
2019-02-18 13:15 ` Laszlo Ersek
2019-02-19 2:46 ` [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration Ni, Ray
2019-02-19 13:25 ` Gao, Liming
2019-02-20 13:27 ` Ni, Ray
2019-02-20 17:43 ` Jordan Justen
2019-02-21 0:15 ` Ni, Ray
2019-02-21 1:03 ` Jordan Justen
2019-02-21 4:43 ` Ni, Ray
2019-02-19 19:27 ` Jordan Justen
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-list 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=CAKv+Gu-v2YCfg44yPJAJBzt9OhtWq2koP2HpfQ5rT_Tc+kZb1Q@mail.gmail.com \
--to=devel@edk2.groups.io \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox