From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.88, mailfrom: jordan.l.justen@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by groups.io with SMTP; Wed, 10 Apr 2019 11:54:26 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2019 11:54:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,334,1549958400"; d="scan'208";a="134652649" Received: from askirtik-mobl1.amr.corp.intel.com (HELO localhost) ([10.254.188.249]) by orsmga006.jf.intel.com with ESMTP; 10 Apr 2019 11:54:24 -0700 MIME-Version: 1.0 In-Reply-To: References: <20190410084000.19660-1-jordan.l.justen@intel.com> To: Ard Biesheuvel , edk2-devel-groups-io From: "Jordan Justen" Cc: Liu Yu , Ray Ni , Andrew Fish , Laszlo Ersek , Leif Lindholm , Michael D Kinney Subject: Re: [edk2-devel] [PATCH v2 0/6] Fix PEI Core issue during TemporaryRamMigration Message-ID: <155492246399.23894.17031399011378142482@jljusten-skl> User-Agent: alot/0.8 Date: Wed, 10 Apr 2019 11:54:24 -0700 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2019-04-10 09:41:43, Ard Biesheuvel wrote: > On Wed, 10 Apr 2019 at 01:41, Jordan Justen w= rote: > > > > https://github.com/jljusten/edk2.git temp-ram-support-v2 > > > > https://github.com/jljusten/edk2/commits/temp-ram-support-v2 > > > > v2: > > * Add AARCH64 and ARM assembly >=20 > Hi Jordan, >=20 > I'm not sure I'm following the reasoning behind this. Did you see the explanation in patch 1 commit message? Could you reply there with questions, or maybe I should try to expand on that? > Does this fix an issue we currently have on ARM systems? Yes, but I don't know of a case where it has been observed on AARCH64/ARM. Nevertheless, as far as I can tell, a similar issue could happen because the current implementation relies on non-spec'd behavior of code gen within a C function. (Not the C calling convention, but what code does with inside the function between calls.) > And how did you build and/or test OVMF for ARM? I built ArmVirtPkg for AARCH64 and ARM on x86_64 Linux with a cross-compiler, and ran it with qemu. -Jordan >=20 > > * Drop IA32 and X64 .S source files > > * Adjust PEI_CORE_TEMPORARY_RAM_TRANSITION pointer in the assembly > > code based on the stack pointer change before & after > > TemporaryRamSupport->TemporaryRamMigration > > * Drop extra cleanup patches for OvmfPkg & EmulatorPkg. These were > > just complicating the series. > > > > This series fixes an issue that, while rare, is possible based on the > > way the TemporaryRamSupport PPI is defined along with how it is used > > by the PEI Core. > > > > Liu Yu reported a boot issue with EmulatorPkg, which I believe was > > caused by this issue. > > > > The details of the issue are described in the commit message of the > > "MdeModulePkg/Core/Pei: Add interface for assembly based > > TemporaryRamSupport" patch. > > > > Testing: > > > > I tested building and booting in several scenarios: > > > > * OVMF IA32 & X64 on Linux > > * ArmVirtPkg AARCH64 & ARM on x86_64 Linux > > * EmulatorPkg IA32 & X64 on Linux > > > > Untested: > > > > * My system does not reproduce the issue that Liu Yu reported with > > EmulatorPkg, so I can't say that I have verified that issue. > > * Building on windows > > * AARCH64/ARM TemporaryRamMigration.asm sources