public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Lendacky, Thomas" <thomas.lendacky@amd.com>
To: devel@edk2.groups.io
Cc: Jordan Justen <jordan.l.justen@intel.com>,
	Laszlo Ersek <lersek@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Liming Gao <liming.gao@intel.com>,
	Eric Dong <eric.dong@intel.com>, Ray Ni <ray.ni@intel.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	Julien Grall <julien@xen.org>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Andrew Fish <afish@apple.com>
Subject: [PATCH v2 0/3] XCODE5 toolchain binary patching fix
Date: Wed,  6 May 2020 11:32:59 -0500	[thread overview]
Message-ID: <cover.1588782781.git.thomas.lendacky@amd.com> (raw)


BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2340

Commit 2db0ccc2d7fe ("UefiCpuPkg: Update CpuExceptionHandlerLib pass
XCODE5 tool chain") introduced binary patching in the
ExceptionHandlerAsm.nasm in order to support the XCODE5 toolchain.
However, the CpuExceptionHandlerLib can be used during SEC phase which
would result in binary patching of flash.

This series creates a new CpuExceptionHandlerLib file to support
the required binary patching for the XCODE5 toolchain, while reverting
the changes from commit 2db0ccc2d7fe in the standard file. As the Pei,
Dxe and SMM versions of the library operate in memory (as opposed to
flash), only the SEC/PEI version is of the library is updated to use the
version of the ExceptionHandlerAsm.nasm that does not perform binary
patching.

This is accomplished in phases:
  - Create a new XCODE5 specific version of the ExceptionHandlerAsm.nasm
    file and update all CpuExceptionHandler INF files to use it while also
    creating a new SEC/PEI CpuExceptionHandler INF file specifically for
    the XCODE5 toolchain.
  - Update all package DSC files that use the SecPeiCpuExceptionHandlerLib
    version of the library to use the XCODE5 version of the library,
    Xcode5SecPeiCpuExceptionHandlerLib, when the XCODE5 toolchain is used.
  - Revert the changes made by commit 2db0ccc2d7fe in the standard file
    and update the SecPeiCpuExceptionHandlerLib.inf file to use the
    standard file.

I don't have access to an XCODE5 toolchain setup, so I have not tested
this with XCODE5. I would like to request that someone who does please
test this.

Also, will this change have an impact on any of the platform builds
outside of this tree? In other words, should the new INF be the one that
uses the reverted ExceptionHandlerAsm.nasm file and it be called something
like BaseSecPeiCpuExceptionHandlerLib.inf?

---

These patches are based on commit:
befd18fca68b ("EmbeddedPkg/EmbeddedPkg.dsc: remove some stale component references")

Cc: Andrew Fish <afish@apple.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>

Changes since v1:
- Only apply the revert to the Sec/Pei CpuExceptionHandler library and
  leave the Pei, Dxe and Smm versions using the binary patching version.
- Generate a unique file GUID for the new library INF file and create
  a corresponding UNI file.
- Remove any references to SEV-ES (original patches accidentally submitted
  from wrong tree).

Tom Lendacky (3):
  UefiCpuPkg/CpuExceptionHandler: Make XCODE5 changes toolchain specific
  OvmfPkg: Use toolchain appropriate CpuExceptionHandlerLib
  UefiCpuPkg/CpuExceptionHandler: Revert CpuExceptionHandler binary
    patching

 OvmfPkg/OvmfPkgIa32.dsc                       |   4 +
 OvmfPkg/OvmfPkgIa32X64.dsc                    |   4 +
 OvmfPkg/OvmfPkgX64.dsc                        |   4 +
 OvmfPkg/OvmfXen.dsc                           |   4 +
 UefiCpuPkg/UefiCpuPkg.dsc                     |   5 +
 .../DxeCpuExceptionHandlerLib.inf             |   2 +-
 .../PeiCpuExceptionHandlerLib.inf             |   2 +-
 .../SmmCpuExceptionHandlerLib.inf             |   2 +-
 .../Xcode5SecPeiCpuExceptionHandlerLib.inf    |  54 +++
 .../X64/ExceptionHandlerAsm.nasm              |  25 +-
 .../X64/Xcode5ExceptionHandlerAsm.nasm        | 396 ++++++++++++++++++
 .../Xcode5SecPeiCpuExceptionHandlerLib.uni    |  17 +
 12 files changed, 497 insertions(+), 22 deletions(-)
 create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
 create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerAsm.nasm
 create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.uni

-- 
2.17.1


             reply	other threads:[~2020-05-06 16:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 16:32 Lendacky, Thomas [this message]
2020-05-06 16:33 ` [PATCH v2 1/3] UefiCpuPkg/CpuExceptionHandler: Make XCODE5 changes toolchain specific Lendacky, Thomas
2020-05-06 19:01   ` Laszlo Ersek
2020-05-06 20:37     ` [edk2-devel] " Lendacky, Thomas
2020-05-06 16:33 ` [PATCH v2 2/3] OvmfPkg: Use toolchain appropriate CpuExceptionHandlerLib Lendacky, Thomas
2020-05-06 19:04   ` Laszlo Ersek
2020-05-06 16:33 ` [PATCH v2 3/3] UefiCpuPkg/CpuExceptionHandler: Revert CpuExceptionHandler binary patching Lendacky, Thomas
2020-05-06 19:31   ` Laszlo Ersek
2020-05-06 19:53 ` [PATCH v2 0/3] XCODE5 toolchain binary patching fix Laszlo Ersek

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=cover.1588782781.git.thomas.lendacky@amd.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