Re: [edk2-devel] Patch List for 202002 stable tag

[Liming Gao]

Hi, Stewards and all:
  Below three patches status are updated. If you have no other comments, I will 
create edk2-stable202002 tomorrow and send the announcement. 

https://edk2.groups.io/g/devel/message/55105 [PATCH 0/2] UefiCpuPkg/Library: 
Fix bug in MpInitLib (BZ: 2556) 
[Liming 2020-02-28] The solution is under discussion. The submitter requests 
this issue to be fixed happen reasonably soon. So, it may not catch this stable 
tag.
[Liming 2020-03-03] The solution is finalized. The patch passed reviewed. Now, 
it can catch this stable tag stable202002. The package maintainer submitted it 
in edk2 master 4c0f6e349d32cf27a7104ddd3e729d6ebc88ea70. PR: 
https://github.com/tianocore/edk2/pull/410

https://edk2.groups.io/g/devel/message/54992 [Patch 
1/1][edk2-stable202002]BaseTools: Fixed a regression issue in Makefile for 
incremental build (BZ: 2563)
[Liming 2020-02-28] This patch has passed review. This regression causes the 
basic incremental build not work with VS nmake tool. The fix is clear. So, it 
need to catch this stable tag.
[Liming 2020-03-03] It is regarded as the critical fix. It was submitted in 
edk2 master at 2be4828af1c92a848af90429a9a0b44544c80553. PR: 
https://github.com/tianocore/edk2/pull/409

https://edk2.groups.io/g/devel/message/54995 [PATCH v1] ShellPkg: Fix 'ping' 
command Ip4 receive flow. (BZ: 2032)
[Liming 2020-02-28] This is the issue in ShellPkg. It may not be critical 
issue, and defer after this stable tag.
[Liming 2020-03-03] The submitted advised moving this issue out of CVE scope 
(and from stable-202002). So, it will defer after this stable tag.

Thanks
Liming
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Leif Lindholm
Sent: 2020年2月28日 20:48
To: Gao, Liming 
Cc: Laszlo Ersek ; devel@edk2.groups.io; Kinney, Michael D 
; af...@apple.com; Guptha, Soumya K 
; Marvin Häuser ; Gao, 
Zhichao ; 'ard.biesheu...@linaro.org' 
; Wu, Hao A ; vit9696 
; gaurav.j...@nxp.com; Ni, Ray ; 
Feng, Bob C ; maciej.rab...@linux.intel.com; 
leo.du...@amd.com
Subject: Re: [edk2-devel] Patch List for 202002 stable tag

On Fri, Feb 28, 2020 at 04:13:09 +, Gao, Liming wrote:
> > > I agree it needs to catch the stable tag. If it affects only VS 
> > > builds then I am not going to insist on extending the hard freeze, 
> > > but I (technically on holiday today/tomorrow) don't have time to 
> > > dig much deeper into it.
> > >
> [Liming] This fix is to restore the original behavior before the 
> commit 818283de3f6d for !INCLUDE style in Makefile generation. It does 
> update GNUmakefile and VS makefile generation. Because it just 
> restores original behavior, its quality risk is low. So, I suggest to catch 
> it in this stable tag on current release planning.

If it is *just* a revert, then the risk is often low enough to not slip the 
date. But I think, as you say, this is something that restores original 
behaviour - but leaving the code different from the original.

> > > However, I think the process is pretty clear that this *should* 
> > > extend the hard freeze.
>
> [Liming] I am not aware of the process to extend the hard freeze. But, 
> you think more time is required for the review and test on the critical bug 
> fix. I am OK.
> 
> > > I will note that from the trail (commitdate of 818283de3f6d until
> > > BZ2563 was raised) it appears that detecting this bug itself, 
> > > which went in two days before the soft freeze, took 15 days.
> 
> [Liming] Yes. It takes 15 days to expose this issue. 
> 
> > I agree with Liming's analysis on the patches (i.e., what goes in 
> > and what gets postponed), and I agree with Leif that we should 
> > extend the hard freeze by at least a couple of days.
>
> [Liming] If you both agree to extend the hard freeze, I have no objection. 
> I request to extend few days instead of few weeks if no other critical issues 
> are reported. 
> Then, the impact of the community can be reduced. 
> 
> > This is not unusual. Originally I thought that edk2 freeze and 
> > release dates were set in stone, but then Mike explained to me that 
> > that had never been the intent. And other open source projects do 
> > several pre-releases (rc0, rc1,  pre-releases with "release 
> > critical" (rc) bug fixes), before a final release. For example, QEMU 
> > regularly plans
> > rc0..rc2 or even rc3, and then *optionally* adds an rc4 if even rc3 
> > receives significant bugfixes. The idea is that the final release / 
> > tag should be preceded by a silent / calm period, where we've waited 
> > a few days and become reasonably convinced that "OK, there's nothing 
> > else we should obviously fix right now".
> > 
> > I wouldn't immediately suggest a full week extension, but maybe 
> > until March 4th (middle of next week)?
> [Liming] March 4th is one good choice to reserve few days for the different 
> time zone people.
> If no more feedback, I will send announcement to delay this stable tag on Feb 
> 28th (00:00:00 UTC-8).

I am OK with March 4th.

Thanks

Re: [edk2-devel] [PATCH 09/13] OvmfPkg: implement QEMU loader library for X86 with legacy fallback

[Laszlo Ersek]

On 03/02/20 08:29, Ard Biesheuvel wrote:
> Implement another version of QemuLoadImageLib that uses LoadImage and
> StartImage, but falls back to the legacy Linux loader code if that
> fails. The logic in the legacy fallback routines is identical to the
> current QEMU linux loader for X64 and IA32.
> 
> Note the use of a LoadedImage pseudo-protocol for the legacy loaded
> image: this makes it possible to expose the LoadImage/StartImage
> abstraction for the legacy loader, using the EFI paradigm of
> identifying loaded image solely by a handle. The pseudo-protocol
> record type and the use of CR() is to get DEBUG coverage for the code
> that deals with these handles.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c   | 562 
> 
>  OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf |  42 ++
>  OvmfPkg/OvmfPkg.dec |   1 +
>  3 files changed, 605 insertions(+)

(1) "-C 41 --find-copies-harder" displays this lib instance as a
modified version of the generic instance (from patch#4). Please sync
this instance too with those comments (whichever apply).

> diff --git a/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c 
> b/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
> new file mode 100644
> index ..a1ced417d1cc
> --- /dev/null
> +++ b/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
> @@ -0,0 +1,562 @@
> +/**  @file
> +  X86 specific implementation of QemuLoadImageLib library class interface
> +  with support for loading mixed mode images and non-EFI stub images
> +
> +  Copyright (c) 2020, ARM Ltd. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#pragma pack (1)
> +typedef struct {
> +  EFI_DEVICE_PATH_PROTOCOL  FilePathHeader;
> +  CHAR16FilePath[sizeof (L"kernel")];
> +} KERNEL_FILE_DEVPATH;
> +
> +typedef struct {
> +  VENDOR_DEVICE_PATHVenMediaNode;
> +  KERNEL_FILE_DEVPATH   FileNode;
> +  EFI_DEVICE_PATH_PROTOCOL  EndNode;
> +} KERNEL_VENMEDIA_FILE_DEVPATH;
> +#pragma pack ()
> +
> +STATIC CONST KERNEL_VENMEDIA_FILE_DEVPATH mKernelDevicePath = {
> +  {
> +{
> +  MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP,
> +  { sizeof (VENDOR_DEVICE_PATH) }
> +},
> +QEMU_KERNEL_LOADER_FS_MEDIA_GUID
> +  }, {
> +{
> +  MEDIA_DEVICE_PATH, MEDIA_FILEPATH_DP,
> +  { sizeof (KERNEL_FILE_DEVPATH) }
> +},
> +L"kernel",
> +  }, {
> +END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
> +{ sizeof (EFI_DEVICE_PATH_PROTOCOL) }
> +  }
> +};
> +
> +typedef struct {
> +  VOID*SetupBuf;
> +  VOID*KernelBuf;
> +  CHAR8   *CommandLine;
> +  VOID*InitrdData;
> +  UINTN   SetupSize;
> +  UINTN   KernelInitialSize;
> +  UINTN   InitrdSize;
> +  UINTN   CommandLineSize;
> +} QEMU_LEGACY_LOADED_IMAGE;
> +
> +#define QEMU_LEGACY_LOADED_IMAGE_SIG \
> +  SIGNATURE_64 ('Q', 'L', 'O', 'A', 'D', 'I', 'M', 'G')
> +
> +typedef struct {
> +  UINT64Signature;
> +  QEMU_LEGACY_LOADED_IMAGE  LoadedImage;
> +} QEMU_LEGACY_LOADED_IMAGE_REC;
> +
> +#define QEMU_LEGACY_LOADED_IMAGE_REC_FROM_LOADED_IMAGE(ImagePointer) \
> +CR (ImagePointer, QEMU_LEGACY_LOADED_IMAGE_REC, LoadedImage, \
> +  QEMU_LEGACY_LOADED_IMAGE_SIG)
> +

I don't understand:

- why we define two structures here (QEMU_LEGACY_LOADED_IMAGE and
QEMU_LEGACY_LOADED_IMAGE_REC),

- and the related use of a Signature + CR().

These tools help if we have a pre-defined -- e.g., standard -- protocol,
for which we'd like to provide an implementation, and we need to carry
some auxiliary ("private") data for every protocol instance that we
produce. In that case, we embed the pre-defined protocol structure in
our own, and use CR() / Signature etc. to arrive at our own container
structure, from a pointer to the pre-defined protocol. This is all
motivated by the fact that the member functions of the pre-defined
protocol take a "This" pointer to said pre-defined protocol.

But in our case here, this use case doesn't seem to apply. We do not
embed a pre-defined protocol structure; we define a brand new inner
structure, and we introduce a brand new protocol GUID for it. We don't
have any pre-existent function prototype that can only take a pointer to
QEMU_LEGACY_LOADED_IMAGE, from which we'd have to arrive at
QEMU_LEGACY_LOADED_IMAGE_REC.

(2) So that makes me think we should simply drop the macro and the
wrapper structure.

> +STATIC
> +VOID
> +FreeLegacyImage (
> +  IN  QEMU_LEGACY_LOADED_IMAGE *LoadedImage
> +  )
> +{
> +  if (LoadedImage->SetupBuf != NULL) {
> +FreePages (LoadedImage->SetupBuf,
> +  EFI_SIZE_TO_PAGES (LoadedImage->SetupSize));
> +  }
> +  if (LoadedIm

Re: [edk2-devel] [PATCH 10/13] OvmfPkg: add new QEMU kernel image loader components

[Laszlo Ersek]

On 03/02/20 08:29, Ard Biesheuvel wrote:
> Add the components that expose the QEMU abstract loader file system so
> that we can switch over our PlatformBmLib over to it in a subsequent
> patch.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 2 ++
>  OvmfPkg/OvmfPkgIa32.fdf| 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc | 2 ++
>  OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
>  OvmfPkg/OvmfPkgX64.dsc | 2 ++
>  OvmfPkg/OvmfPkgX64.fdf | 1 +
>  6 files changed, 9 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 8d91903f8b4e..2cc924a6986a 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -361,6 +361,7 @@ [LibraryClasses.common.DXE_DRIVER]
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> +  
> QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
>  !if $(TPM2_ENABLE) == TRUE
>Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
>  !endif
> @@ -711,6 +712,7 @@ [Components]
>NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
>  !endif
>}
> +  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
>OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>OvmfPkg/Virtio10Dxe/Virtio10.inf
>OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index f57de4a26f92..61287bd51f84 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -242,6 +242,7 @@ [FV.DXEFV]
>  INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>  INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>  INF  MdeModulePkg/Application/UiApp/UiApp.inf
> +INF  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
>  INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>  INF  MdeModulePkg/Universal/PrintDxe/PrintDxe.inf
>  INF  MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 842b4a028913..21d1f156973b 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -365,6 +365,7 @@ [LibraryClasses.common.DXE_DRIVER]
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> +  
> QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
>  !if $(TPM2_ENABLE) == TRUE
>Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
>  !endif
> @@ -723,6 +724,7 @@ [Components.X64]
>NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
>  !endif
>}
> +  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
>OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>OvmfPkg/Virtio10Dxe/Virtio10.inf
>OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index 69c133ec08d5..7b770f8fa424 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -243,6 +243,7 @@ [FV.DXEFV]
>  INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>  INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>  INF  MdeModulePkg/Application/UiApp/UiApp.inf
> +INF  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
>  INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>  INF  MdeModulePkg/Universal/PrintDxe/PrintDxe.inf
>  INF  MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 0b1e45d1f15a..f3d0f18db7e2 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -365,6 +365,7 @@ [LibraryClasses.common.DXE_DRIVER]
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> +  
> QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
>  !if $(TPM2_ENABLE) == TRUE
>Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
>  !endif
> @@ -721,6 +722,7 @@ [Components]
>NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
>  !endif
>}
> +  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
>OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>OvmfPkg/Virtio10Dxe/Virtio10.inf
>OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index 69c133ec08d5..7b770f8fa424 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -243,6 +243,7 @@ [FV.DXEFV]
>  INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>  INF  MdeModuleP

Re: [edk2-devel] [PATCH 11/13] OvmfPkg/PlatformBootManagerLib: switch to QemuLoadImageLib

[Laszlo Ersek]

On 03/02/20 08:29, Ard Biesheuvel wrote:
> Replace the open coded sequence to load Linux on x86 with a short and
> generic sequence invoking QemuLoadImageLib, which can be provided by
> a generic version that only supports the LoadImage and StartImage boot
> services, and one that incorporates the entire legacy loading sequence
> as well.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   2 +-
>  OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c   | 157 
> +++-
>  2 files changed, 24 insertions(+), 135 deletions(-)
> 
> diff --git 
> a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index f89cce187942..40ac5dd7f9d5 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -48,7 +48,7 @@ [LibraryClasses]
>NvVarsFileLib
>QemuFwCfgLib
>QemuFwCfgS3Lib
> -  LoadLinuxLib
> +  QemuLoadImageLib
>QemuBootOrderLib
>ReportStatusCodeLib
>UefiLib
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c 
> b/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
> index ddfef925edd3..a15b48d360d2 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
> @@ -9,11 +9,8 @@
>  
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 
> +#include 
>  #include 
> -#include 
>  #include 
>  
>  
> @@ -23,146 +20,38 @@ TryRunningQemuKernel (
>)
>  {
>EFI_STATUSStatus;
> -  UINTN KernelSize;
> -  UINTN KernelInitialSize;
> -  VOID  *KernelBuf;
> -  UINTN SetupSize;
> -  VOID  *SetupBuf;
> -  UINTN CommandLineSize;
> -  CHAR8 *CommandLine;
> -  UINTN InitrdSize;
> -  VOID* InitrdData;
> -
> -  SetupBuf = NULL;
> -  SetupSize = 0;
> -  KernelBuf = NULL;
> -  KernelInitialSize = 0;
> -  CommandLine = NULL;
> -  CommandLineSize = 0;
> -  InitrdData = NULL;
> -  InitrdSize = 0;
> -
> -  if (!QemuFwCfgIsAvailable ()) {
> -return EFI_NOT_FOUND;
> -  }
> -
> -  QemuFwCfgSelectItem (QemuFwCfgItemKernelSize);
> -  KernelSize = (UINTN) QemuFwCfgRead64 ();
> -
> -  QemuFwCfgSelectItem (QemuFwCfgItemKernelSetupSize);
> -  SetupSize = (UINTN) QemuFwCfgRead64 ();
> -
> -  if (KernelSize == 0 || SetupSize == 0) {
> -DEBUG ((EFI_D_INFO, "qemu -kernel was not used.\n"));
> -return EFI_NOT_FOUND;
> -  }
> -
> -  SetupBuf = LoadLinuxAllocateKernelSetupPages (EFI_SIZE_TO_PAGES 
> (SetupSize));
> -  if (SetupBuf == NULL) {
> -DEBUG ((EFI_D_ERROR, "Unable to allocate memory for kernel setup!\n"));
> -return EFI_OUT_OF_RESOURCES;
> -  }
> -
> -  DEBUG ((EFI_D_INFO, "Setup size: 0x%x\n", (UINT32) SetupSize));
> -  DEBUG ((EFI_D_INFO, "Reading kernel setup image ..."));
> -  QemuFwCfgSelectItem (QemuFwCfgItemKernelSetupData);
> -  QemuFwCfgReadBytes (SetupSize, SetupBuf);
> -  DEBUG ((EFI_D_INFO, " [done]\n"));
> -
> -  Status = LoadLinuxCheckKernelSetup (SetupBuf, SetupSize);
> -  if (EFI_ERROR (Status)) {
> -goto FreeAndReturn;
> -  }
> -
> -  Status = LoadLinuxInitializeKernelSetup (SetupBuf);
> -  if (EFI_ERROR (Status)) {
> -goto FreeAndReturn;
> -  }
> -
> -  KernelInitialSize = LoadLinuxGetKernelSize (SetupBuf, KernelSize);
> -  if (KernelInitialSize == 0) {
> -Status = EFI_UNSUPPORTED;
> -goto FreeAndReturn;
> -  }
> -
> -  KernelBuf = LoadLinuxAllocateKernelPages (
> -SetupBuf,
> -EFI_SIZE_TO_PAGES (KernelInitialSize));
> -  if (KernelBuf == NULL) {
> -DEBUG ((EFI_D_ERROR, "Unable to allocate memory for kernel!\n"));
> -Status = EFI_OUT_OF_RESOURCES;
> -goto FreeAndReturn;
> -  }
> -
> -  DEBUG ((EFI_D_INFO, "Kernel size: 0x%x\n", (UINT32) KernelSize));
> -  DEBUG ((EFI_D_INFO, "Reading kernel image ..."));
> -  QemuFwCfgSelectItem (QemuFwCfgItemKernelData);
> -  QemuFwCfgReadBytes (KernelSize, KernelBuf);
> -  DEBUG ((EFI_D_INFO, " [done]\n"));
> -
> -  QemuFwCfgSelectItem (QemuFwCfgItemCommandLineSize);
> -  CommandLineSize = (UINTN) QemuFwCfgRead64 ();
> -
> -  if (CommandLineSize > 0) {
> -CommandLine = LoadLinuxAllocateCommandLinePages (
> -EFI_SIZE_TO_PAGES (CommandLineSize));
> -QemuFwCfgSelectItem (QemuFwCfgItemCommandLineData);
> -QemuFwCfgReadBytes (CommandLineSize, CommandLine);
> -  } else {
> -CommandLine = NULL;
> -  }
> -
> -  Status = LoadLinuxSetCommandLine (SetupBuf, CommandLine);
> -  if (EFI_ERROR (Status)) {
> -goto FreeAndReturn;
> -  }
> -
> -  QemuFwCfgSelectItem (QemuFwCfgItemInitrdSize);
> -  InitrdSize = (UINTN) QemuFwCfgRead64 ();
> -
> -  if (InitrdSiz

Re: [edk2-devel] [PATCH 11/13] OvmfPkg/PlatformBootManagerLib: switch to QemuLoadImageLib

[Laszlo Ersek]

On 03/03/20 10:52, Laszlo Ersek wrote:
> On 03/02/20 08:29, Ard Biesheuvel wrote:
>> Replace the open coded sequence to load Linux on x86 with a short and
>> generic sequence invoking QemuLoadImageLib, which can be provided by
>> a generic version that only supports the LoadImage and StartImage boot
>> services, and one that incorporates the entire legacy loading sequence
>> as well.
>>
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   2 +-
>>  OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c   | 157 
>> +++-
>>  2 files changed, 24 insertions(+), 135 deletions(-)
>>
>> diff --git 
>> a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
>> b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>> index f89cce187942..40ac5dd7f9d5 100644
>> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>> @@ -48,7 +48,7 @@ [LibraryClasses]
>>NvVarsFileLib
>>QemuFwCfgLib
>>QemuFwCfgS3Lib
>> -  LoadLinuxLib
>> +  QemuLoadImageLib
>>QemuBootOrderLib
>>ReportStatusCodeLib
>>UefiLib
>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c 
>> b/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
>> index ddfef925edd3..a15b48d360d2 100644
>> --- a/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
>> @@ -9,11 +9,8 @@
>>  
>>  #include 
>>  #include 
>> -#include 
>> -#include 
>> -#include 
>> +#include 
>>  #include 
>> -#include 
>>  #include 
>>  
>>  
>> @@ -23,146 +20,38 @@ TryRunningQemuKernel (
>>)
>>  {
>>EFI_STATUSStatus;
>> -  UINTN KernelSize;
>> -  UINTN KernelInitialSize;
>> -  VOID  *KernelBuf;
>> -  UINTN SetupSize;
>> -  VOID  *SetupBuf;
>> -  UINTN CommandLineSize;
>> -  CHAR8 *CommandLine;
>> -  UINTN InitrdSize;
>> -  VOID* InitrdData;
>> -
>> -  SetupBuf = NULL;
>> -  SetupSize = 0;
>> -  KernelBuf = NULL;
>> -  KernelInitialSize = 0;
>> -  CommandLine = NULL;
>> -  CommandLineSize = 0;
>> -  InitrdData = NULL;
>> -  InitrdSize = 0;
>> -
>> -  if (!QemuFwCfgIsAvailable ()) {
>> -return EFI_NOT_FOUND;
>> -  }
>> -
>> -  QemuFwCfgSelectItem (QemuFwCfgItemKernelSize);
>> -  KernelSize = (UINTN) QemuFwCfgRead64 ();
>> -
>> -  QemuFwCfgSelectItem (QemuFwCfgItemKernelSetupSize);
>> -  SetupSize = (UINTN) QemuFwCfgRead64 ();
>> -
>> -  if (KernelSize == 0 || SetupSize == 0) {
>> -DEBUG ((EFI_D_INFO, "qemu -kernel was not used.\n"));
>> -return EFI_NOT_FOUND;
>> -  }
>> -
>> -  SetupBuf = LoadLinuxAllocateKernelSetupPages (EFI_SIZE_TO_PAGES 
>> (SetupSize));
>> -  if (SetupBuf == NULL) {
>> -DEBUG ((EFI_D_ERROR, "Unable to allocate memory for kernel setup!\n"));
>> -return EFI_OUT_OF_RESOURCES;
>> -  }
>> -
>> -  DEBUG ((EFI_D_INFO, "Setup size: 0x%x\n", (UINT32) SetupSize));
>> -  DEBUG ((EFI_D_INFO, "Reading kernel setup image ..."));
>> -  QemuFwCfgSelectItem (QemuFwCfgItemKernelSetupData);
>> -  QemuFwCfgReadBytes (SetupSize, SetupBuf);
>> -  DEBUG ((EFI_D_INFO, " [done]\n"));
>> -
>> -  Status = LoadLinuxCheckKernelSetup (SetupBuf, SetupSize);
>> -  if (EFI_ERROR (Status)) {
>> -goto FreeAndReturn;
>> -  }
>> -
>> -  Status = LoadLinuxInitializeKernelSetup (SetupBuf);
>> -  if (EFI_ERROR (Status)) {
>> -goto FreeAndReturn;
>> -  }
>> -
>> -  KernelInitialSize = LoadLinuxGetKernelSize (SetupBuf, KernelSize);
>> -  if (KernelInitialSize == 0) {
>> -Status = EFI_UNSUPPORTED;
>> -goto FreeAndReturn;
>> -  }
>> -
>> -  KernelBuf = LoadLinuxAllocateKernelPages (
>> -SetupBuf,
>> -EFI_SIZE_TO_PAGES (KernelInitialSize));
>> -  if (KernelBuf == NULL) {
>> -DEBUG ((EFI_D_ERROR, "Unable to allocate memory for kernel!\n"));
>> -Status = EFI_OUT_OF_RESOURCES;
>> -goto FreeAndReturn;
>> -  }
>> -
>> -  DEBUG ((EFI_D_INFO, "Kernel size: 0x%x\n", (UINT32) KernelSize));
>> -  DEBUG ((EFI_D_INFO, "Reading kernel image ..."));
>> -  QemuFwCfgSelectItem (QemuFwCfgItemKernelData);
>> -  QemuFwCfgReadBytes (KernelSize, KernelBuf);
>> -  DEBUG ((EFI_D_INFO, " [done]\n"));
>> -
>> -  QemuFwCfgSelectItem (QemuFwCfgItemCommandLineSize);
>> -  CommandLineSize = (UINTN) QemuFwCfgRead64 ();
>> -
>> -  if (CommandLineSize > 0) {
>> -CommandLine = LoadLinuxAllocateCommandLinePages (
>> -EFI_SIZE_TO_PAGES (CommandLineSize));
>> -QemuFwCfgSelectItem (QemuFwCfgItemCommandLineData);
>> -QemuFwCfgReadBytes (CommandLineSize, CommandLine);
>> -  } else {
>> -CommandLine = NULL;
>> -  }
>> -
>> -  Status = LoadLinuxSetCommandLine (SetupBuf, CommandLine);
>> -  if

Re: [edk2-devel] [PATCH 09/13] OvmfPkg: implement QEMU loader library for X86 with legacy fallback

[Ard Biesheuvel]

On Tue, 3 Mar 2020 at 10:45, Laszlo Ersek  wrote:
>
> On 03/02/20 08:29, Ard Biesheuvel wrote:
> > Implement another version of QemuLoadImageLib that uses LoadImage and
> > StartImage, but falls back to the legacy Linux loader code if that
> > fails. The logic in the legacy fallback routines is identical to the
> > current QEMU linux loader for X64 and IA32.
> >
> > Note the use of a LoadedImage pseudo-protocol for the legacy loaded
> > image: this makes it possible to expose the LoadImage/StartImage
> > abstraction for the legacy loader, using the EFI paradigm of
> > identifying loaded image solely by a handle. The pseudo-protocol
> > record type and the use of CR() is to get DEBUG coverage for the code
> > that deals with these handles.
> >
> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c   | 562 
> > 
> >  OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf |  42 ++
> >  OvmfPkg/OvmfPkg.dec |   1 +
> >  3 files changed, 605 insertions(+)
>
> (1) "-C 41 --find-copies-harder" displays this lib instance as a
> modified version of the generic instance (from patch#4). Please sync
> this instance too with those comments (whichever apply).
>
> > diff --git a/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c 
> > b/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
> > new file mode 100644
> > index ..a1ced417d1cc
> > --- /dev/null
> > +++ b/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
> > @@ -0,0 +1,562 @@
> > +/**  @file
> > +  X86 specific implementation of QemuLoadImageLib library class interface
> > +  with support for loading mixed mode images and non-EFI stub images
> > +
> > +  Copyright (c) 2020, ARM Ltd. All rights reserved.
> > +
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +**/
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#pragma pack (1)
> > +typedef struct {
> > +  EFI_DEVICE_PATH_PROTOCOL  FilePathHeader;
> > +  CHAR16FilePath[sizeof (L"kernel")];
> > +} KERNEL_FILE_DEVPATH;
> > +
> > +typedef struct {
> > +  VENDOR_DEVICE_PATHVenMediaNode;
> > +  KERNEL_FILE_DEVPATH   FileNode;
> > +  EFI_DEVICE_PATH_PROTOCOL  EndNode;
> > +} KERNEL_VENMEDIA_FILE_DEVPATH;
> > +#pragma pack ()
> > +
> > +STATIC CONST KERNEL_VENMEDIA_FILE_DEVPATH mKernelDevicePath = {
> > +  {
> > +{
> > +  MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP,
> > +  { sizeof (VENDOR_DEVICE_PATH) }
> > +},
> > +QEMU_KERNEL_LOADER_FS_MEDIA_GUID
> > +  }, {
> > +{
> > +  MEDIA_DEVICE_PATH, MEDIA_FILEPATH_DP,
> > +  { sizeof (KERNEL_FILE_DEVPATH) }
> > +},
> > +L"kernel",
> > +  }, {
> > +END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
> > +{ sizeof (EFI_DEVICE_PATH_PROTOCOL) }
> > +  }
> > +};
> > +
> > +typedef struct {
> > +  VOID*SetupBuf;
> > +  VOID*KernelBuf;
> > +  CHAR8   *CommandLine;
> > +  VOID*InitrdData;
> > +  UINTN   SetupSize;
> > +  UINTN   KernelInitialSize;
> > +  UINTN   InitrdSize;
> > +  UINTN   CommandLineSize;
> > +} QEMU_LEGACY_LOADED_IMAGE;
> > +
> > +#define QEMU_LEGACY_LOADED_IMAGE_SIG \
> > +  SIGNATURE_64 ('Q', 'L', 'O', 'A', 'D', 'I', 'M', 'G')
> > +
> > +typedef struct {
> > +  UINT64Signature;
> > +  QEMU_LEGACY_LOADED_IMAGE  LoadedImage;
> > +} QEMU_LEGACY_LOADED_IMAGE_REC;
> > +
> > +#define QEMU_LEGACY_LOADED_IMAGE_REC_FROM_LOADED_IMAGE(ImagePointer) \
> > +CR (ImagePointer, QEMU_LEGACY_LOADED_IMAGE_REC, LoadedImage, \
> > +  QEMU_LEGACY_LOADED_IMAGE_SIG)
> > +
>
> I don't understand:
>
> - why we define two structures here (QEMU_LEGACY_LOADED_IMAGE and
> QEMU_LEGACY_LOADED_IMAGE_REC),
>
> - and the related use of a Signature + CR().
>
> These tools help if we have a pre-defined -- e.g., standard -- protocol,
> for which we'd like to provide an implementation, and we need to carry
> some auxiliary ("private") data for every protocol instance that we
> produce. In that case, we embed the pre-defined protocol structure in
> our own, and use CR() / Signature etc. to arrive at our own container
> structure, from a pointer to the pre-defined protocol. This is all
> motivated by the fact that the member functions of the pre-defined
> protocol take a "This" pointer to said pre-defined protocol.
>
> But in our case here, this use case doesn't seem to apply. We do not
> embed a pre-defined protocol structure; we define a brand new inner
> structure, and we introduce a brand new protocol GUID for it. We don't
> have any pre-existent function prototype that can only take a pointer to
> QEMU_LEGACY_LOADED_IMAGE, from which we'd have to arrive at
> QEMU_LEGACY_LOADED_IMAGE_REC.
>

OK. I liked the extra check against

Re: [edk2-devel] [PATCH 12/13] OvmfPkg/QemuKernelLoaderFsDxe: add support for new Linux initrd device path

[Laszlo Ersek]

On 03/02/20 08:29, Ard Biesheuvel wrote:
> Linux v5.7 will introduce a new method to load the initial ramdisk
> (initrd) from the loader, using the LoadFile2 protocol installed on a
> special vendor GUIDed media device path.
> 
> Add support for this to our QEMU command line kernel/initrd loader.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c   | 79 
> 
>  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf |  2 +
>  2 files changed, 81 insertions(+)
> 
> diff --git a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c 
> b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
> index 77d8fedb738a..415946edf22a 100644
> --- a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
> +++ b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
> @@ -13,15 +13,18 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  //
> @@ -84,6 +87,19 @@ STATIC CONST SINGLE_VENMEDIA_NODE_DEVPATH 
> mFileSystemDevicePath = {
>}
>  };
>  
> +STATIC CONST SINGLE_VENMEDIA_NODE_DEVPATH mInitrdDevicePath = {
> +  {
> +{
> +  MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP,
> +  { sizeof (VENDOR_DEVICE_PATH) }
> +},
> +LINUX_EFI_INITRD_MEDIA_GUID
> +  }, {
> +END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
> +{ sizeof (EFI_DEVICE_PATH_PROTOCOL) }
> +  }
> +};
> +
>  //
>  // The "file in the EFI stub filesystem" abstraction.
>  //
> @@ -839,6 +855,48 @@ STATIC CONST EFI_SIMPLE_FILE_SYSTEM_PROTOCOL mFileSystem 
> = {
>StubFileSystemOpenVolume
>  };
>  
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +InitrdLoadFile2 (
> +  IN EFI_LOAD_FILE2_PROTOCOL  *This,
> +  IN EFI_DEVICE_PATH_PROTOCOL *FilePath,
> +  IN BOOLEAN  BootPolicy,
> +  IN OUT UINTN*BufferSize,
> +  IN VOID *Buffer OPTIONAL
> +  )
> +{
> +  CONST KERNEL_BLOB   *InitrdBlob = &mKernelBlob[KernelBlobTypeInitrd];
> +
> +  ASSERT (InitrdBlob->Size > 0);
> +
> +  if (BootPolicy) {
> +return EFI_UNSUPPORTED;
> +  }
> +
> +  if (BufferSize == NULL || !IsDevicePathValid (FilePath, 0)) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  if (FilePath->Type != END_DEVICE_PATH_TYPE ||
> +  FilePath->SubType != END_ENTIRE_DEVICE_PATH_SUBTYPE) {
> +return EFI_NOT_FOUND;
> +  }
> +
> +  if (Buffer == NULL || *BufferSize < InitrdBlob->Size) {
> +*BufferSize = InitrdBlob->Size;
> +return EFI_BUFFER_TOO_SMALL;
> +  }
> +
> +  CopyMem (Buffer, InitrdBlob->Data, InitrdBlob->Size);
> +
> +  *BufferSize = InitrdBlob->Size;
> +  return EFI_SUCCESS;
> +}
> +
> +STATIC CONST EFI_LOAD_FILE2_PROTOCOL mInitrdLoadFile2 = {
> +  InitrdLoadFile2,
> +};
>  
>  //
>  // Utility functions.
> @@ -945,6 +1003,7 @@ QemuKernelLoaderFsDxeEntrypoint (
>KERNEL_BLOB   *KernelBlob;
>EFI_STATUSStatus;
>EFI_HANDLEFileSystemHandle;
> +  EFI_HANDLEInitrdLoadFile2Handle;
>  
>if (!QemuFwCfgIsAvailable ()) {
>  return EFI_NOT_FOUND;
> @@ -989,8 +1048,28 @@ QemuKernelLoaderFsDxeEntrypoint (
>  goto FreeBlobs;
>}
>  
> +  if (KernelBlob[KernelBlobTypeInitrd].Size > 0) {
> +InitrdLoadFile2Handle = NULL;
> +Status = gBS->InstallMultipleProtocolInterfaces (&InitrdLoadFile2Handle,
> +&gEfiDevicePathProtocolGuid,  &mInitrdDevicePath,
> +&gEfiLoadFile2ProtocolGuid,   &mInitrdLoadFile2,
> +NULL);
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "%a: InstallMultipleProtocolInterfaces(): %r\n",
> +__FUNCTION__, Status));
> +  goto UninstallFileSystemHandle;
> +}
> +  }
> +
>return EFI_SUCCESS;
>  
> +UninstallFileSystemHandle:
> +  Status = gBS->UninstallMultipleProtocolInterfaces (FileSystemHandle,
> +  &gEfiDevicePathProtocolGuid,   &mFileSystemDevicePath,
> +  &gEfiSimpleFileSystemProtocolGuid, &mFileSystem,
> +  NULL);
> +  ASSERT_EFI_ERROR (Status);
> +
>  FreeBlobs:
>while (BlobType > 0) {
>  CurrentBlob = &mKernelBlob[--BlobType];
> diff --git a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf 
> b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
> index f4b50c265027..737f9b87a7c7 100644
> --- a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
> +++ b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
> @@ -28,6 +28,7 @@ [LibraryClasses]
>BaseLib
>BaseMemoryLib
>DebugLib
> +  DevicePathLib
>MemoryAllocationLib
>UefiBootServicesTableLib
>QemuFwCfgLib
> @@ -42,6 +43,7 @@ [Guids]
>  
>  [Protocols]
>gEfiDevicePathProtocolGuid## PRODUCES
> +  gEfiLoadFile2ProtocolGuid 

Re: [edk2-devel] [PATCH 13/13] OvmfPkg: use generic QEMU image loader for secure boot enabled builds

[Laszlo Ersek]

On 03/02/20 08:29, Ard Biesheuvel wrote:
> The QemuLoadImageLib implementation we currently use for all OVMF
> builds copies the behavior of the QEMU loader code that precedes it,
> which is to disregard UEFI secure boot policies entirely when it comes
> to loading kernel images that have been specified on the QEMU command
> line. This behavior deviates from ArmVirtQemu based builds, which do
> take UEFI secure boot policies into account, and refuse to load images
> from the command line that cannot be authenticated.
> 
> The disparity was originally due to the fact that the QEMU command line
> kernel loader did not use LoadImage and StartImage at all, but this
> changed recently, and now, there are only a couple of reasons left to
> stick with the legacy loader:
> - it permits loading images that lack a valid PE/COFF header,
> - it permits loading X64 kernels on IA32 firmware running on a X64
>   capable system.
> 
> Since every non-authentic PE/COFF image can trivially be converted into
> an image that lacks a valid PE/COFF header, the former case can simply
> not be supported in a UEFI secure boot context. The latter case is highly
> theoretical, given that one could easily switch to native X64 firmware in
> a VM scenario.
> 
> That leaves us with little justification to use the legacy loader at all
> when UEFI secure boot policies are in effect, so let's switch to the
> generic loader for UEFI secure boot enabled builds.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 4 
>  OvmfPkg/OvmfPkgIa32X64.dsc | 4 
>  OvmfPkg/OvmfPkgX64.dsc | 4 
>  3 files changed, 12 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 2cc924a6986a..eceddb71948f 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -361,7 +361,11 @@ [LibraryClasses.common.DXE_DRIVER]
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  
> QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
> +!else
>
> QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
> +!endif
>  !if $(TPM2_ENABLE) == TRUE
>Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
>  !endif
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 21d1f156973b..8bdf2e692b00 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -365,7 +365,11 @@ [LibraryClasses.common.DXE_DRIVER]
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  
> QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
> +!else
>
> QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
> +!endif
>  !if $(TPM2_ENABLE) == TRUE
>Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
>  !endif
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index f3d0f18db7e2..bc0a3e438d2a 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -365,7 +365,11 @@ [LibraryClasses.common.DXE_DRIVER]
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  
> QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
> +!else
>
> QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
> +!endif
>  !if $(TPM2_ENABLE) == TRUE
>Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
>  !endif
> 

Reviewed-by: Laszlo Ersek 

Thank you!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55300): https://edk2.groups.io/g/devel/message/55300
Mute This Topic: https://groups.io/mt/71669027/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 12/13] OvmfPkg/QemuKernelLoaderFsDxe: add support for new Linux initrd device path

[Ard Biesheuvel]

On Tue, 3 Mar 2020 at 11:10, Laszlo Ersek  wrote:
>
> On 03/02/20 08:29, Ard Biesheuvel wrote:
> > Linux v5.7 will introduce a new method to load the initial ramdisk
> > (initrd) from the loader, using the LoadFile2 protocol installed on a
> > special vendor GUIDed media device path.
> >
> > Add support for this to our QEMU command line kernel/initrd loader.
> >
> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c   | 79 
> > 
> >  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf |  2 +
> >  2 files changed, 81 insertions(+)
> >
> > diff --git a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c 
> > b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
> > index 77d8fedb738a..415946edf22a 100644
> > --- a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
> > +++ b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
> > @@ -13,15 +13,18 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  //
> > @@ -84,6 +87,19 @@ STATIC CONST SINGLE_VENMEDIA_NODE_DEVPATH 
> > mFileSystemDevicePath = {
> >}
> >  };
> >
> > +STATIC CONST SINGLE_VENMEDIA_NODE_DEVPATH mInitrdDevicePath = {
> > +  {
> > +{
> > +  MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP,
> > +  { sizeof (VENDOR_DEVICE_PATH) }
> > +},
> > +LINUX_EFI_INITRD_MEDIA_GUID
> > +  }, {
> > +END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
> > +{ sizeof (EFI_DEVICE_PATH_PROTOCOL) }
> > +  }
> > +};
> > +
> >  //
> >  // The "file in the EFI stub filesystem" abstraction.
> >  //
> > @@ -839,6 +855,48 @@ STATIC CONST EFI_SIMPLE_FILE_SYSTEM_PROTOCOL 
> > mFileSystem = {
> >StubFileSystemOpenVolume
> >  };
> >
> > +STATIC
> > +EFI_STATUS
> > +EFIAPI
> > +InitrdLoadFile2 (
> > +  IN EFI_LOAD_FILE2_PROTOCOL  *This,
> > +  IN EFI_DEVICE_PATH_PROTOCOL *FilePath,
> > +  IN BOOLEAN  BootPolicy,
> > +  IN OUT UINTN*BufferSize,
> > +  IN VOID *Buffer OPTIONAL
> > +  )
> > +{
> > +  CONST KERNEL_BLOB   *InitrdBlob = &mKernelBlob[KernelBlobTypeInitrd];
> > +
> > +  ASSERT (InitrdBlob->Size > 0);
> > +
> > +  if (BootPolicy) {
> > +return EFI_UNSUPPORTED;
> > +  }
> > +
> > +  if (BufferSize == NULL || !IsDevicePathValid (FilePath, 0)) {
> > +return EFI_INVALID_PARAMETER;
> > +  }
> > +
> > +  if (FilePath->Type != END_DEVICE_PATH_TYPE ||
> > +  FilePath->SubType != END_ENTIRE_DEVICE_PATH_SUBTYPE) {
> > +return EFI_NOT_FOUND;
> > +  }
> > +
> > +  if (Buffer == NULL || *BufferSize < InitrdBlob->Size) {
> > +*BufferSize = InitrdBlob->Size;
> > +return EFI_BUFFER_TOO_SMALL;
> > +  }
> > +
> > +  CopyMem (Buffer, InitrdBlob->Data, InitrdBlob->Size);
> > +
> > +  *BufferSize = InitrdBlob->Size;
> > +  return EFI_SUCCESS;
> > +}
> > +
> > +STATIC CONST EFI_LOAD_FILE2_PROTOCOL mInitrdLoadFile2 = {
> > +  InitrdLoadFile2,
> > +};
> >
> >  //
> >  // Utility functions.
> > @@ -945,6 +1003,7 @@ QemuKernelLoaderFsDxeEntrypoint (
> >KERNEL_BLOB   *KernelBlob;
> >EFI_STATUSStatus;
> >EFI_HANDLEFileSystemHandle;
> > +  EFI_HANDLEInitrdLoadFile2Handle;
> >
> >if (!QemuFwCfgIsAvailable ()) {
> >  return EFI_NOT_FOUND;
> > @@ -989,8 +1048,28 @@ QemuKernelLoaderFsDxeEntrypoint (
> >  goto FreeBlobs;
> >}
> >
> > +  if (KernelBlob[KernelBlobTypeInitrd].Size > 0) {
> > +InitrdLoadFile2Handle = NULL;
> > +Status = gBS->InstallMultipleProtocolInterfaces 
> > (&InitrdLoadFile2Handle,
> > +&gEfiDevicePathProtocolGuid,  &mInitrdDevicePath,
> > +&gEfiLoadFile2ProtocolGuid,   &mInitrdLoadFile2,
> > +NULL);
> > +if (EFI_ERROR (Status)) {
> > +  DEBUG ((DEBUG_ERROR, "%a: InstallMultipleProtocolInterfaces(): %r\n",
> > +__FUNCTION__, Status));
> > +  goto UninstallFileSystemHandle;
> > +}
> > +  }
> > +
> >return EFI_SUCCESS;
> >
> > +UninstallFileSystemHandle:
> > +  Status = gBS->UninstallMultipleProtocolInterfaces (FileSystemHandle,
> > +  &gEfiDevicePathProtocolGuid,   
> > &mFileSystemDevicePath,
> > +  &gEfiSimpleFileSystemProtocolGuid, &mFileSystem,
> > +  NULL);
> > +  ASSERT_EFI_ERROR (Status);
> > +
> >  FreeBlobs:
> >while (BlobType > 0) {
> >  CurrentBlob = &mKernelBlob[--BlobType];
> > diff --git a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf 
> > b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
> > index f4b50c265027..737f9b87a7c7 100644
> > --- a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
> > +++ b/OvmfPkg/QemuKernelLoaderFsDxe/QemuK

Re: [edk2-devel] [PATCH v2 09/16] OvmfPkg/CpuHotplugSmm: add function for collecting CPUs with events

[Laszlo Ersek]

On 03/02/20 21:34, Philippe Mathieu-Daudé wrote:
> On 2/26/20 11:11 PM, Laszlo Ersek wrote:
>> Add a function that collects the APIC IDs of CPUs that have just been
>> hot-plugged, or are about to be hot-unplugged.
>>
>> Pending events are only located and never cleared; QEMU's AML needs the
>> firmware to leave the status bits intact in the hotplug register block.
>>
>> Cc: Ard Biesheuvel 
>> Cc: Igor Mammedov 
>> Cc: Jiewen Yao 
>> Cc: Jordan Justen 
>> Cc: Michael Kinney 
>> Cc: Philippe Mathieu-Daudé 
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
>> Signed-off-by: Laszlo Ersek 
>> Acked-by: Ard Biesheuvel 
>> ---
>>
>> Notes:
>>  v2:
>>   - Pick up Ard's Acked-by, which is conditional on approval
>> from Intel
>>    reviewers on Cc. (I'd like to save Ard the churn of re-acking
>>    unmodified patches.)
>>
>>   OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h |   2 +
>>   OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf   |   1 +
>>   OvmfPkg/CpuHotplugSmm/ApicId.h    |  23 +++
>>   OvmfPkg/CpuHotplugSmm/QemuCpuhp.h |  20 ++-
>>   OvmfPkg/CpuHotplugSmm/QemuCpuhp.c | 171
>> +++-
>>   5 files changed, 211 insertions(+), 6 deletions(-)
>>
>> diff --git a/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h
>> b/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h
>> index 3d013633501b..a34a6d3fae61 100644
>> --- a/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h
>> +++ b/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h
>> @@ -13,32 +13,34 @@
>>   The new ("modern") hotplug interface appeared in QEMU v2.7.0.
>>     The macros in this header file map to the minimal subset of
>> the modern
>>   interface that OVMF needs.
>>   **/
>>     #ifndef QEMU_CPU_HOTPLUG_H_
>>   #define QEMU_CPU_HOTPLUG_H_
>>     #include 
>>     //
>>   // Each register offset is:
>>   // - relative to the board-dependent IO base address of the register
>> block,
>>   // - named QEMU_CPUHP_(R|W|RW)_*, according to the possible access
>> modes of the
>>   //   register,
>>   // - followed by distinguished bitmasks or values in the register.
>>   //
>>   #define QEMU_CPUHP_R_CMD_DATA2   0x0
>>     #define QEMU_CPUHP_R_CPU_STAT    0x4
>>   #define QEMU_CPUHP_STAT_ENABLED    BIT0
>> +#define QEMU_CPUHP_STAT_INSERT BIT1
>> +#define QEMU_CPUHP_STAT_REMOVE BIT2
>>     #define QEMU_CPUHP_RW_CMD_DATA   0x8
>>     #define QEMU_CPUHP_W_CPU_SEL 0x0
>>     #define QEMU_CPUHP_W_CMD 0x5
>>   #define QEMU_CPUHP_CMD_GET_PENDING 0x0
>>   #define QEMU_CPUHP_CMD_GET_ARCH_ID 0x3
>>     #endif // QEMU_CPU_HOTPLUG_H_
>> diff --git a/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
>> b/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
>> index ac4ca4c1f4f2..ab690a9e5e20 100644
>> --- a/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
>> +++ b/OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
>> @@ -3,44 +3,45 @@
>>   #
>>   # Copyright (c) 2020, Red Hat, Inc.
>>   #
>>   # SPDX-License-Identifier: BSD-2-Clause-Patent
>>   ##
>>     [Defines]
>>     INF_VERSION    = 1.29
>>     PI_SPECIFICATION_VERSION   = 0x00010046   
>> # PI-1.7.0
>>     BASE_NAME  = CpuHotplugSmm
>>     FILE_GUID  = 84EEA114-C6BE-4445-8F90-51D97863E363
>>     MODULE_TYPE    = DXE_SMM_DRIVER
>>     ENTRY_POINT    = CpuHotplugEntry
>>     #
>>   # The following information is for reference only and not required
>> by the build
>>   # tools.
>>   #
>>   # VALID_ARCHITECTURES    = IA32 X64
>>   #
>>     [Sources]
>> +  ApicId.h
>>     CpuHotplug.c
>>     QemuCpuhp.c
>>     QemuCpuhp.h
>>     [Packages]
>>     MdePkg/MdePkg.dec
>>     OvmfPkg/OvmfPkg.dec
>>     [LibraryClasses]
>>     BaseLib
>>     DebugLib
>>     MmServicesTableLib
>>     PcdLib
>>     UefiDriverEntryPoint
>>     [Protocols]
>>     gEfiMmCpuIoProtocolGuid  
>> ## CONSUMES
>>     [Pcd]
>>     gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
>> ## CONSUMES
>>     [FeaturePcd]
>> diff --git a/OvmfPkg/CpuHotplugSmm/ApicId.h
>> b/OvmfPkg/CpuHotplugSmm/ApicId.h
>> new file mode 100644
>> index ..3c365148ed02
>> --- /dev/null
>> +++ b/OvmfPkg/CpuHotplugSmm/ApicId.h
>> @@ -0,0 +1,23 @@
>> +/** @file
>> +  Type and macro definitions for representing and printing APIC IDs,
>> compatibly
>> +  with the LocalApicLib and PrintLib classes, respectively.
>> +
>> +  Copyright (c) 2020, Red Hat, Inc.
>> +
>> +  SPDX-License-Identifier: BSD-2-Clause-Patent
>> +**/
>> +
>> +#ifndef APIC_ID_H_
>> +#define APIC_ID_H_
>> +
>> +//
>> +// The type that LocalApicLib represents an APIC ID with.
>> +//
>> +typedef UINT32 APIC_ID;
>> +
>> +//
>> +// The PrintLib conversion specification for formatting an APIC_ID.
>> +//
>> +#define FMT_APIC_ID "0x%08x"
>> +
>> +#endif // APIC_ID_H_
>>

[edk2-devel][PATCH 0/5] Platform/RPi: User config improvements

[Pete Batard]

This series improves on the configuration options made available to users
in the firmware/BIOS setup.

It adds 2 new options, one aimed at limiting the total amount of RAM
presented to the OS to 3 GB (currently needed for xHCI on Linux) and the
other toggling the provision of the Device Tree, which can be used to
force ACPI mode.

Combined, these two options remove the need for the ACPI_BASIC_MODE_ENABLE
build parameter we were previously using, and allow more fine grained
control, including adding the ability for Pi 3 users to enforce ACPI.

Finally, some cleanup and harmonization of the user settings menu forms
is applied.


Andrei Warkentin (3):
  Platform/RPi: Add firmware call to read installed memory size
  Platform/RPi: Separate RAM descriptors between 0-3 GB and 3+ GB
  Platform/RPi: Make 3GB/4GB a runtime (BIOS setup) choice

Pete Batard (2):
  Platform/RPi: Make Device Tree provision a runtime (BIOS setup) choice
  Platform/RPi/ConfigDxe: Improve RPi configuration forms

 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 66 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf   |  9 ++-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni| 38 
++---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr| 84 
+---
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c   |  5 ++
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf |  3 +
 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 10 +--
 Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c   | 29 ++-
 Platform/RaspberryPi/Include/Protocol/RpiFirmware.h| 47 
++-
 Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf   |  3 -
 Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c  | 33 
+---
 Platform/RaspberryPi/RPi3/RPi3.dsc | 11 +++
 Platform/RaspberryPi/RPi4/RPi4.dsc | 16 ++--
 Platform/RaspberryPi/RPi4/RPi4.fdf |  2 -
 Platform/RaspberryPi/RPi4/Readme.md| 15 ++--
 Platform/RaspberryPi/RaspberryPi.dec   |  6 +-
 16 files changed, 283 insertions(+), 94 deletions(-)

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55303): https://edk2.groups.io/g/devel/message/55303
Mute This Topic: https://groups.io/mt/71697494/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel][PATCH 1/5] Platform/RPi: Add firmware call to read installed memory size

[Pete Batard]

From: Andrei Warkentin 

Add a new RPiFirmwareGetModelInstalledMB () call in RpiFirmwareDxe
to return the amount of detected installed RAM on the system (in MB).

Use the new call in PlatformSmbiosDxe.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 10 ++---
 Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c   | 29 
+++-
 Platform/RaspberryPi/Include/Protocol/RpiFirmware.h| 47 
+++-
 3 files changed, 59 insertions(+), 27 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
index f25c439f89c8..5585cb846f41 100644
--- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
+++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -870,21 +870,19 @@ MemArrMapInfoUpdateSmbiosType19 (
   )
 {
   EFI_STATUS Status;
-  UINT32 BoardRevision = 0;
+  UINT32 InstalledMB = 0;
 
   // Note: Type 19 addresses are expressed in KB, not bytes
   // The memory layout used in all known Pi SoC's starts at 0
   mMemArrMapInfoType19.StartingAddress = 0;
+
   // The minimum RAM size used on any Raspberry Pi model is 256 MB
   mMemArrMapInfoType19.EndingAddress = 256 * 1024;
-  Status = mFwProtocol->GetModelRevision (&BoardRevision);
+  Status = mFwProtocol->GetModelInstalledMB (&InstalledMB);
   if (Status != EFI_SUCCESS) {
 DEBUG ((DEBUG_WARN, "Couldn't get the board memory size - defaulting to 
256 MB: %r\n", Status));
   } else {
-// 
www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
-// Bits [20-22] indicate the amount of memory starting with 256MB (000b)
-// and doubling in size for each value (001b = 512 MB, 010b = 1GB, etc.)
-mMemArrMapInfoType19.EndingAddress <<= (BoardRevision >> 20) & 0x07;
+mMemArrMapInfoType19.EndingAddress = InstalledMB * 1024;
   }
   mMemArrMapInfoType19.EndingAddress -= 1;
 
diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
index 75826fdc0e53..40c78b5d57cf 100644
--- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
+++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -606,6 +606,32 @@ RpiFirmwareGetModelName (
   }
 }
 
+STATIC
+EFI_STATUS
+EFIAPI
+RPiFirmwareGetModelInstalledMB (
+  OUT   UINT32 *InstalledMB
+  )
+{
+  EFI_STATUS Status;
+  UINT32 Revision;
+
+  Status = RpiFirmwareGetModelRevision(&Revision);
+  if (EFI_ERROR(Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Could not get the board revision: Status == 
%r\n",
+  __FUNCTION__, Status));
+return EFI_DEVICE_ERROR;
+  }
+
+  //
+  // 
www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
+  // Bits [20-22] indicate the amount of memory starting with 256MB (000b)
+  // and doubling in size for each value (001b = 512 MB, 010b = 1GB, etc.)
+  //
+  *InstalledMB = 256 << ((Revision >> 20) & 0x07);
+  return EFI_SUCCESS;
+}
+
 STATIC
 EFI_STATUS
 EFIAPI
@@ -1236,7 +1262,8 @@ STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL 
mRpiFirmwareProtocol = {
   RpiFirmwareGetFirmwareRevision,
   RpiFirmwareGetManufacturerName,
   RpiFirmwareGetCpuName,
-  RpiFirmwareGetArmMemory
+  RpiFirmwareGetArmMemory,
+  RPiFirmwareGetModelInstalledMB,
 };
 
 /**
diff --git a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h 
b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
index e3287e3c040f..108becbd3b6d 100644
--- a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
+++ b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
@@ -115,6 +115,12 @@ EFI_STATUS
   UINT32 *Revision
   );
 
+typedef
+EFI_STATUS
+(EFIAPI *GET_MODEL_INSTALLED_MB) (
+  UINT32 *InstalledMB
+  );
+
 typedef
 CHAR8*
 (EFIAPI *GET_MANUFACTURER_NAME) (
@@ -135,26 +141,27 @@ EFI_STATUS
   );
 
 typedef struct {
-  SET_POWER_STATE   SetPowerState;
-  GET_MAC_ADDRESS   GetMacAddress;
-  GET_COMMAND_LINE  GetCommandLine;
-  GET_CLOCK_RATEGetClockRate;
-  GET_CLOCK_RATEGetMaxClockRate;
-  GET_CLOCK_RATEGetMinClockRate;
-  SET_CLOCK_RATESetClockRate;
-  GET_FBGetFB;
-  FREE_FB   FreeFB;
-  GET_FB_SIZE   GetFBSize;
-  SET_LED   SetLed;
-  GET_SERIALGetSerial;
-  GET_MODEL GetModel;
-  GET_MODEL_REVISIONGetModelRevision;
-  GET_MODEL_NAMEGetModelName;
-  GET_MODEL_FAMILY  GetModelFamily;
-  GET_FIRMWARE_REVISION GetFirmwareRevision;
-  GET_MANUFACTURER_NAME GetManufacturerName;
-  GET_CPU_NAME  GetCpuName;
-  GET_ARM_MEM   GetArmMem;
+  SET_POWER_STATESetPowerState;
+  GET_MAC_ADDRESSGetMacAddress;
+  GET_COMMAND_LINE   GetCommandLine;
+  GET_CLOCK_RATE GetClockRate;
+  GET_CLOCK_RATE GetMaxClockRate;
+  GET_CLOCK_RATE GetMinClockRate;
+  SET_CLOCK_RATE Set

[edk2-devel][PATCH 4/5] Platform/RPi: Make Device Tree provision a runtime (BIOS setup) choice

[Pete Batard]

With this and the previous commit, ACPI_BASIC_MODE_ENABLE becomes
superfluous so remove it.

New option defaults to enabled on Pi 3, disabled on Pi 4.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  |  8 
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 21 

 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c|  5 +
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf  |  3 +++
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  5 +
 Platform/RaspberryPi/RPi4/RPi4.dsc  | 10 +-
 Platform/RaspberryPi/RPi4/RPi4.fdf  |  2 --
 Platform/RaspberryPi/RPi4/Readme.md | 15 ++
 Platform/RaspberryPi/RaspberryPi.dec|  4 +---
 11 files changed, 60 insertions(+), 19 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 451a419a5358..31a62094e33e 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -151,6 +151,14 @@ SetupVariables (
 PcdSet32 (PcdRamLimitTo3GB, 0);
   }
 
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"OptDeviceTree",
+  &gConfigDxeFormSetGuid,
+  NULL, &Size, &Var32);
+  if (EFI_ERROR (Status)) {
+PcdSet32 (PcdOptDeviceTree, PcdGet32 (PcdOptDeviceTree));
+  }
+
   Size = sizeof (UINT32);
   Status = gRT->GetVariable (L"SdIsArasan",
   &gConfigDxeFormSetGuid,
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index 407aac89c7b3..736d49df562b 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -72,6 +72,7 @@ [Pcd]
   gRaspberryPiTokenSpaceGuid.PcdDebugShowUEFIExit
   gRaspberryPiTokenSpaceGuid.PcdDisplayEnableScaledVModes
   gRaspberryPiTokenSpaceGuid.PcdDisplayEnableSShot
+  gRaspberryPiTokenSpaceGuid.PcdOptDeviceTree
   gRaspberryPiTokenSpaceGuid.PcdRamMoreThan3GB
   gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 830533a9dc49..2e79e322e558 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -46,6 +46,11 @@
 #string STR_ADVANCED_3GB_OFF #language en-US "Disabled"
 #string STR_ADVANCED_3GB_ON  #language en-US "Enabled"
 
+#string STR_ADVANCED_DT_PROMPT   #language en-US "Device Tree"
+#string STR_ADVANCED_DT_HELP #language en-US "Disable this option to 
force OSes such as GNU/Linux to use ACPI"
+#string STR_ADVANCED_DT_OFF  #language en-US "Disabled (Force ACPI)"
+#string STR_ADVANCED_DT_ON   #language en-US "Enabled"
+
 /*
  * MMC/SD configuration.
  */
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index 483edd7459c5..d16058da4926 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -85,6 +85,14 @@ typedef struct {
   UINT32 Enabled;
 } ADVANCED_RAM_LIMIT_TO_3GB_VARSTORE_DATA;
 
+typedef struct {
+  /*
+   * 0 - Do not provide a Device Tree to the OS
+   * 1 - Provide a Device Tree to the OS
+   */
+  UINT32 Enabled;
+} ADVANCED_DEVICE_TREE_VARSTORE_DATA;
+
 typedef struct {
   /*
* 0 - Don't disable multi-block.
@@ -162,6 +170,11 @@ formset
   name  = RamLimitTo3GB,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
+efivarstore ADVANCED_DEVICE_TREE_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = OptDeviceTree,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore MMC_DISMULTI_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = MmcDisableMulti,
@@ -279,6 +292,14 @@ formset
   option text = STRING_TOKEN(STR_ADVANCED_3GB_ON), value = 1, 
flags = 0;
   endoneof;
 endif;
+
+oneof varid = OptDeviceTree.Enabled,
+prompt  = STRING_TOKEN(STR_ADVANCED_DT_PROMPT),
+help= STRING_TOKEN(STR_ADVANCED_DT_HELP),
+flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+option text = STRING_TOKEN(STR_ADVANCED_DT_OFF), value = 0, flags 
= 0;
+option text = STRING_TOKEN(STR_ADVANCED_DT_ON), value = 1, flags = 
DEFAULT;
+endoneof;
 endform;
 
 form formid = 0x1003,
diff --git a/Platform/RaspberryPi/Drivers/

[edk2-devel][PATCH 3/5] Platform/RPi: Make 3GB/4GB a runtime (BIOS setup) choice

[Pete Batard]

From: Andrei Warkentin 

Currently some OSes (e.g FreeBSD) can make full use of the maximum
4 GB of RAM a Raspberry Pi 4 can offer, whereas others (e.g. Linux)
must be restricted to only the first 3 GB.

Previously this was a compile-time choice chosen by PcdAcpiBasicMode,
and now we make it user-selectable. The default is a 3 GB limit.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 58 

 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  8 ++-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni | 11 
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 41 ++
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc  |  6 ++
 Platform/RaspberryPi/RaspberryPi.dec|  4 +-
 7 files changed, 120 insertions(+), 14 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 2f48ca0dd758..451a419a5358 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -11,11 +11,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +28,8 @@ extern UINT8 ConfigDxeHiiBin[];
 extern UINT8 ConfigDxeStrings[];
 
 STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
+STATIC UINT32 mModelFamily = 0;
+STATIC UINT32 mModelInstalledMB = 0;
 
 /*
  * The GUID inside Platform/RaspberryPi/RPi3/AcpiTables/AcpiTables.inf and
@@ -129,6 +133,24 @@ SetupVariables (
 PcdSet32 (PcdCustomCpuClock, PcdGet32 (PcdCustomCpuClock));
   }
 
+  if (mModelFamily >= 4 && mModelInstalledMB > 3 * 1024) {
+/*
+ * This allows changing PcdRamLimitTo3GB in forms.
+ */
+PcdSet32 (PcdRamMoreThan3GB, 1);
+
+Size = sizeof (UINT32);
+Status = gRT->GetVariable (L"RamLimitTo3GB",
+   &gConfigDxeFormSetGuid,
+   NULL, &Size, &Var32);
+if (EFI_ERROR (Status)) {
+  PcdSet32 (PcdRamLimitTo3GB, PcdGet32 (PcdRamLimitTo3GB));
+}
+  } else {
+PcdSet32 (PcdRamMoreThan3GB, 0);
+PcdSet32 (PcdRamLimitTo3GB, 0);
+  }
+
   Size = sizeof (UINT32);
   Status = gRT->GetVariable (L"SdIsArasan",
   &gConfigDxeFormSetGuid,
@@ -224,7 +246,6 @@ ApplyVariables (
   UINT32 CpuClock = PcdGet32 (PcdCpuClock);
   UINT32 CustomCpuClock = PcdGet32 (PcdCustomCpuClock);
   UINT32 Rate = 0;
-  UINT32 ModelFamily = 0;
 
   if (CpuClock != 0) {
 if (CpuClock == 2) {
@@ -258,15 +279,18 @@ ApplyVariables (
 DEBUG ((DEBUG_INFO, "Current CPU speed is %uHz\n", Rate));
   }
 
-  Status = mFwProtocol->GetModelFamily (&ModelFamily);
-  if (Status != EFI_SUCCESS) {
-DEBUG ((DEBUG_ERROR, "Couldn't get the Raspberry Pi model family: %r\n", 
Status));
-  } else {
-DEBUG ((DEBUG_INFO, "Current Raspberry Pi model family is 0x%x\n", 
ModelFamily));
+  if (mModelFamily >= 4 && PcdGet32 (PcdRamLimitTo3GB) == 0) {
+Status = gDS->AddMemorySpace (EfiGcdMemoryTypeSystemMemory, BASE_1GB + 
SIZE_2GB,
+SIZE_1GB - (SIZE_4GB - BCM2711_SOC_REGISTERS),
+EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT | 
EFI_MEMORY_WB);
+ASSERT_EFI_ERROR (Status);
+Status = gDS->SetMemorySpaceAttributes (BASE_1GB + SIZE_2GB,
+SIZE_1GB - (SIZE_4GB - BCM2711_SOC_REGISTERS),
+EFI_MEMORY_WB);
+ASSERT_EFI_ERROR (Status);
   }
 
-
-  if (ModelFamily == 3) {
+  if (mModelFamily == 3) {
 /*
  * Pi 3: either Arasan or SdHost goes to SD card.
  *
@@ -316,7 +340,7 @@ ApplyVariables (
 GpioPinFuncSet (52, Gpio48Group);
 GpioPinFuncSet (53, Gpio48Group);
 
-  } else if (ModelFamily == 4) {
+  } else if (mModelFamily == 4) {
 /*
  * Pi 4: either Arasan or eMMC2 goes to SD card.
  */
@@ -352,7 +376,7 @@ ApplyVariables (
   GpioPinFuncSet (39, GPIO_FSEL_ALT3);
 }
   } else {
-DEBUG ((DEBUG_ERROR, "Model Family %d not supported...\n", ModelFamily));
+DEBUG ((DEBUG_ERROR, "Model Family %d not supported...\n", mModelFamily));
   }
 
   /*
@@ -400,6 +424,20 @@ ConfigInitialize (
 return Status;
   }
 
+  Status = mFwProtocol->GetModelFamily (&mModelFamily);
+  if (Status != EFI_SUCCESS) {
+DEBUG ((DEBUG_ERROR, "Couldn't get the Raspberry Pi model family: %r\n", 
Status));
+  } else {
+DEBUG ((DEBUG_INFO, "Current Raspberry Pi model family is %d\n", 
mModelFamily));
+  }
+
+  Status = mFwProtocol->GetModelInstalledMB (&mModelInstalledMB);
+  if (Status != EFI_SUCCESS) {
+DEBUG ((DEBUG_ERROR, "Couldn't get the Raspberry Pi installed RAM size: 
%r\n", Status));
+  } else {
+DEBUG ((DEBUG_INFO, "Current Raspberry Pi installed RAM size is %d MB\n", 
mModelInstalledMB));
+  }
+
   Status = SetupVariables ();
   if (Status != EFI_SUCCESS) {
 DEBUG ((DEB

[edk2-devel][PATCH 5/5] Platform/RPi/ConfigDxe: Improve RPi configuration forms

[Pete Batard]

Group all SD/MMC settings under the SD/MMC form.
Make CPU settings more prominent.
Harmonise form titles and text content.
Reorder forms in the order they are most likely to be queried.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni | 24 +-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 50 
++--
 2 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 2e79e322e558..77eda96d8136 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -14,11 +14,11 @@
 #string STR_FORM_SET_TITLE_HELP  #language en-US "Press  to configure 
system settings."
 
 /*
- * Chipset config.
+ * Chipset configuration.
  */
 
-#string STR_CHIPSET_FORM_TITLE  #language en-US "Chipset Configuration"
-#string STR_CHIPSET_FORM_SUBTITLE   #language en-US "Note: OS may override 
settings when booted."
+#string STR_CHIPSET_FORM_TITLE  #language en-US "CPU Configuration"
+#string STR_CHIPSET_FORM_SUBTITLE   #language en-US "Note: OS may override 
settings."
 
 #string STR_CHIPSET_CLOCK_CPU_PROMPT #language en-US "CPU Clock"
 #string STR_CHIPSET_CLOCK_CPU_HELP   #language en-US "CPU Speed"
@@ -30,11 +30,6 @@
 #string STR_CHIPSET_CUSTOM_CPU_CLOCK_PROMPT #language en-US "CPU Clock Rate 
(MHz)"
 #string STR_CHIPSET_CUSTOM_CPU_CLOCK_HELP   #language en-US "Adjust the CPU 
speed.\nMin value: 100 MHz\nMax value: 1600 MHz\n\nWarning: Overclocking can 
make the system unbootable!"
 
-#string STR_CHIPSET_SD_PROMPT#language en-US "uSD Routing"
-#string STR_CHIPSET_SD_HELP  #language en-US "Choose host controller 
to drive uSD slot"
-#string STR_CHIPSET_SD_SDHOST#language en-US "Broadcom SDHOST"
-#string STR_CHIPSET_SD_ARASAN#language en-US "Arasan SDHCI"
-
 /*
  * Advanced configuration.
  */
@@ -55,8 +50,13 @@
  * MMC/SD configuration.
  */
 
-#string STR_MMC_FORM_TITLE   #language en-US "SD/MMC Tweaks"
-#string STR_MMC_FORM_SUBTITLE#language en-US "Note: UEFI only, OS will 
override settings when booted."
+#string STR_MMC_FORM_TITLE   #language en-US "SD/MMC Configuration"
+#string STR_MMC_FORM_SUBTITLE#language en-US "Note: UEFI only, OS may 
override settings."
+
+#string STR_MMC_SD_PROMPT#language en-US "uSD Routing"
+#string STR_MMC_SD_HELP  #language en-US "Choose host controller to 
drive uSD slot"
+#string STR_MMC_SD_SDHOST#language en-US "Broadcom SDHOST"
+#string STR_MMC_SD_ARASAN#language en-US "Arasan SDHCI"
 
 #string STR_MMC_DISMULTI_PROMPT  #language en-US "Multi-Block Support"
 #string STR_MMC_DISMULTI_HELP#language en-US "Use CMD18/CMD25 for 
transfers when possible"
@@ -84,7 +84,7 @@
  * Display settings.
  */
 
-#string STR_DISPLAY_FORM_TITLE  #language en-US "Display"
+#string STR_DISPLAY_FORM_TITLE  #language en-US "Display Configuration"
 #string STR_DISPLAY_FORM_SUBTITLE   #language en-US "UEFI video driver 
settings"
 
 #string STR_DISPLAY_VMODES_640_PROMPT  #language en-US "Virtual 640x480"
@@ -109,7 +109,7 @@
 /*
  * Debugging settings go here.
  */
-#string STR_DEBUG_FORM_TITLE#language en-US "Debugging"
+#string STR_DEBUG_FORM_TITLE#language en-US "Debugging Configuration"
 #string STR_DEBUG_FORM_SUBTITLE #language en-US "For UEFI/OS Developers"
 
 #string STR_DEBUG_JTAG_PROMPT   #language en-US "JTAG Routing"
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index d16058da4926..9c2fd64a8e27 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -65,14 +65,6 @@ typedef struct {
   UINT32 Clock;
 } CHIPSET_CUSTOM_CPU_CLOCK_VARSTORE_DATA;
 
-typedef struct {
-  /*
-   * 0 - uSD slot routed to Broadcom SDHOST.
-   * 1 - uSD slot routed to Arasan SDHCI.
-   */
-  UINT32 Routing;
-} CHIPSET_SD_VARSTORE_DATA;
-
 typedef struct {
   /*
* Always set by ConfigDxe prior to HII init to reflect
@@ -93,6 +85,14 @@ typedef struct {
   UINT32 Enabled;
 } ADVANCED_DEVICE_TREE_VARSTORE_DATA;
 
+typedef struct {
+  /*
+   * 0 - uSD slot routed to Broadcom SDHOST.
+   * 1 - uSD slot routed to Arasan SDHCI.
+   */
+  UINT32 Routing;
+} MMC_SD_VARSTORE_DATA;
+
 typedef struct {
   /*
* 0 - Don't disable multi-block.
@@ -155,11 +155,6 @@ formset
   name  = CustomCpuClock,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
-efivarstore CHIPSET_SD_VARSTORE_DATA,
-  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
-  name  = SdIsArasan,
-  guid  = CONFIGDXE_FORM_SET_GUID;
-
 efivarstore ADVANCED_RAM_MORE_THAN_3GB_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VA

[edk2-devel][PATCH 2/5] Platform/RPi: Separate RAM descriptors between 0-3 GB and 3+ GB

[Pete Batard]

From: Andrei Warkentin 

This is required so that we can make the 3 to 4 GB segment of
the Raspberry Pi 4 a user-configurable option.

This also removes the need for the PcdAcpiBasicMode PCD.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf  |  3 --
 Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c | 33 
++--
 2 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf 
b/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf
index 9abcc2cc0075..77cdbe399a06 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf
+++ b/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf
@@ -59,8 +59,5 @@ [FixedPcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
 
-[FeaturePcd]
-  gRaspberryPiTokenSpaceGuid.PcdAcpiBasicMode
-
 [Ppis]
   gArmMpCoreInfoPpiGuid
diff --git a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c 
b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
index 4b388465cdde..3f257d4fa528 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
+++ b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
@@ -25,7 +25,7 @@ UINT32 mBoardRevision;
 
 
 // The total number of descriptors, including the final "end-of-table" 
descriptor.
-#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 10
+#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 11
 
 STATIC BOOLEAN  VirtualMemoryInfoInitialized = FALSE;
 STATIC RPI_MEMORY_REGION_INFO   
VirtualMemoryInfo[MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS];
@@ -60,6 +60,7 @@ ArmPlatformGetVirtualMemoryMap (
 {
   UINTN Index = 0;
   UINTN GpuIndex;
+  INT64 OrigMemorySize;
   INT64 SystemMemorySize;
   ARM_MEMORY_REGION_DESCRIPTOR  *VirtualMemoryTable;
 
@@ -78,7 +79,6 @@ ArmPlatformGetVirtualMemoryMap (
 return;
   }
 
-
   // Firmware Volume
   VirtualMemoryTable[Index].PhysicalBase= FixedPcdGet64 (PcdFdBaseAddress);
   VirtualMemoryTable[Index].VirtualBase = 
VirtualMemoryTable[Index].PhysicalBase;
@@ -155,13 +155,13 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryInfo[Index].Type = RPI_MEM_UNMAPPED_REGION;
   VirtualMemoryInfo[Index++].Name   = L"SoC Reserved (283x)";
 
-  if (FeaturePcdGet (PcdAcpiBasicMode)) {
-//
-// Limit the memory to 3 GB to work around the DMA bugs in the SoC without
-// having to rely on IORT or _DMA descriptions.
-//
-SystemMemorySize = MIN(SystemMemorySize, 3U * SIZE_1GB);
-  }
+  //
+  // By default we limit the memory to 3 GB to work around the DMA bugs in the 
SoC, for
+  // OSes that don't support _DMA range descriptors. On 4GB boards, it's 
runtime
+  // setting to boot with 4GB, and the additional 1GB is added by ConfigDxe.
+  //
+  OrigMemorySize = SystemMemorySize;
+  SystemMemorySize = MIN(SystemMemorySize, 3U * SIZE_1GB);
 
   // If we have RAM above the 1 GB mark, declare it
   if (SystemMemorySize - SIZE_1GB > 0) {
@@ -170,7 +170,20 @@ ArmPlatformGetVirtualMemoryMap (
 VirtualMemoryTable[Index].Length= SystemMemorySize - SIZE_1GB;
 VirtualMemoryTable[Index].Attributes= 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
 VirtualMemoryInfo[Index].Type   = RPI_MEM_BASIC_REGION;
-VirtualMemoryInfo[Index++].Name = L"Extended System RAM";
+VirtualMemoryInfo[Index++].Name = L"Extended System RAM below 3GB";
+  }
+
+  //
+  // If we have RAM above 3 GB mark, declare it so it's mapped, but
+  // don't add it to the memory map. This is done later by ConfigDxe if 
necessary.
+  //
+  if (OrigMemorySize > (3UL * SIZE_1GB)) {
+VirtualMemoryTable[Index].PhysicalBase  = 3UL * SIZE_1GB;
+VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
+VirtualMemoryTable[Index].Length= OrigMemorySize - 
VirtualMemoryTable[Index].PhysicalBase;
+VirtualMemoryTable[Index].Attributes= 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
+VirtualMemoryInfo[Index].Type   = RPI_MEM_UNMAPPED_REGION;
+VirtualMemoryInfo[Index++].Name = L"Extended System RAM above 3GB";
   }
 
   // End of Table
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55305): https://edk2.groups.io/g/devel/message/55305
Mute This Topic: https://groups.io/mt/71697496/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel][PATCH 1/5] Platform/RPi: Add firmware call to read installed memory size

[Ard Biesheuvel]

On Tue, 3 Mar 2020 at 11:33, Pete Batard  wrote:
>
> From: Andrei Warkentin 
>
> Add a new RPiFirmwareGetModelInstalledMB () call in RpiFirmwareDxe
> to return the amount of detected installed RAM on the system (in MB).
>
> Use the new call in PlatformSmbiosDxe.
>
> Signed-off-by: Pete Batard 

Please split this into two patches

> ---
>  Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 10 ++---
>  Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c   | 29 
> +++-
>  Platform/RaspberryPi/Include/Protocol/RpiFirmware.h| 47 
> +++-
>  3 files changed, 59 insertions(+), 27 deletions(-)
>
> diff --git 
> a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
> b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
> index f25c439f89c8..5585cb846f41 100644
> --- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
> +++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
> @@ -870,21 +870,19 @@ MemArrMapInfoUpdateSmbiosType19 (
>)
>  {
>EFI_STATUS Status;
> -  UINT32 BoardRevision = 0;
> +  UINT32 InstalledMB = 0;
>
>// Note: Type 19 addresses are expressed in KB, not bytes
>// The memory layout used in all known Pi SoC's starts at 0
>mMemArrMapInfoType19.StartingAddress = 0;
> +
>// The minimum RAM size used on any Raspberry Pi model is 256 MB
>mMemArrMapInfoType19.EndingAddress = 256 * 1024;
> -  Status = mFwProtocol->GetModelRevision (&BoardRevision);
> +  Status = mFwProtocol->GetModelInstalledMB (&InstalledMB);
>if (Status != EFI_SUCCESS) {
>  DEBUG ((DEBUG_WARN, "Couldn't get the board memory size - defaulting to 
> 256 MB: %r\n", Status));
>} else {
> -// 
> www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
> -// Bits [20-22] indicate the amount of memory starting with 256MB (000b)
> -// and doubling in size for each value (001b = 512 MB, 010b = 1GB, etc.)
> -mMemArrMapInfoType19.EndingAddress <<= (BoardRevision >> 20) & 0x07;
> +mMemArrMapInfoType19.EndingAddress = InstalledMB * 1024;
>}
>mMemArrMapInfoType19.EndingAddress -= 1;
>
> diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
> b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> index 75826fdc0e53..40c78b5d57cf 100644
> --- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> +++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> @@ -606,6 +606,32 @@ RpiFirmwareGetModelName (
>}
>  }
>
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +RPiFirmwareGetModelInstalledMB (
> +  OUT   UINT32 *InstalledMB
> +  )
> +{
> +  EFI_STATUS Status;
> +  UINT32 Revision;
> +
> +  Status = RpiFirmwareGetModelRevision(&Revision);
> +  if (EFI_ERROR(Status)) {
> +DEBUG ((DEBUG_ERROR, "%a: Could not get the board revision: Status == 
> %r\n",
> +  __FUNCTION__, Status));
> +return EFI_DEVICE_ERROR;
> +  }
> +
> +  //
> +  // 
> www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
> +  // Bits [20-22] indicate the amount of memory starting with 256MB (000b)
> +  // and doubling in size for each value (001b = 512 MB, 010b = 1GB, etc.)
> +  //
> +  *InstalledMB = 256 << ((Revision >> 20) & 0x07);
> +  return EFI_SUCCESS;
> +}
> +
>  STATIC
>  EFI_STATUS
>  EFIAPI
> @@ -1236,7 +1262,8 @@ STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL 
> mRpiFirmwareProtocol = {
>RpiFirmwareGetFirmwareRevision,
>RpiFirmwareGetManufacturerName,
>RpiFirmwareGetCpuName,
> -  RpiFirmwareGetArmMemory
> +  RpiFirmwareGetArmMemory,
> +  RPiFirmwareGetModelInstalledMB,
>  };
>
>  /**
> diff --git a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h 
> b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
> index e3287e3c040f..108becbd3b6d 100644
> --- a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
> +++ b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
> @@ -115,6 +115,12 @@ EFI_STATUS
>UINT32 *Revision
>);
>
> +typedef
> +EFI_STATUS
> +(EFIAPI *GET_MODEL_INSTALLED_MB) (
> +  UINT32 *InstalledMB
> +  );
> +
>  typedef
>  CHAR8*
>  (EFIAPI *GET_MANUFACTURER_NAME) (
> @@ -135,26 +141,27 @@ EFI_STATUS
>);
>
>  typedef struct {
> -  SET_POWER_STATE   SetPowerState;
> -  GET_MAC_ADDRESS   GetMacAddress;
> -  GET_COMMAND_LINE  GetCommandLine;
> -  GET_CLOCK_RATEGetClockRate;
> -  GET_CLOCK_RATEGetMaxClockRate;
> -  GET_CLOCK_RATEGetMinClockRate;
> -  SET_CLOCK_RATESetClockRate;
> -  GET_FBGetFB;
> -  FREE_FB   FreeFB;
> -  GET_FB_SIZE   GetFBSize;
> -  SET_LED   SetLed;
> -  GET_SERIALGetSerial;
> -  GET_MODEL GetModel;
> -  GET_MODEL_REVISIONGetModelRevision;
> -  GET_MODEL_NAMEGetModelName;
> -  GET_MODEL_FAMILY  GetModelFamily;
> -  GET_FIRMWARE_REVISION GetFirmwareRevision;
> -  GET_MANUFACTURER_NAME GetManufacturerNam

Re: [edk2-devel][PATCH 2/5] Platform/RPi: Separate RAM descriptors between 0-3 GB and 3+ GB

[Ard Biesheuvel]

On Tue, 3 Mar 2020 at 11:33, Pete Batard  wrote:
>
> From: Andrei Warkentin 
>
> This is required so that we can make the 3 to 4 GB segment of
> the Raspberry Pi 4 a user-configurable option.
>
> This also removes the need for the PcdAcpiBasicMode PCD.
>
> Signed-off-by: Pete Batard 

Please fix the commit log so it is clear what 'this' means

> ---
>  Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf  |  3 --
>  Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c | 33 
> ++--
>  2 files changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf 
> b/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf
> index 9abcc2cc0075..77cdbe399a06 100644
> --- a/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf
> +++ b/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf
> @@ -59,8 +59,5 @@ [FixedPcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
>
> -[FeaturePcd]
> -  gRaspberryPiTokenSpaceGuid.PcdAcpiBasicMode
> -
>  [Ppis]
>gArmMpCoreInfoPpiGuid
> diff --git a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c 
> b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
> index 4b388465cdde..3f257d4fa528 100644
> --- a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
> +++ b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
> @@ -25,7 +25,7 @@ UINT32 mBoardRevision;
>
>
>  // The total number of descriptors, including the final "end-of-table" 
> descriptor.
> -#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 10
> +#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 11
>
>  STATIC BOOLEAN  VirtualMemoryInfoInitialized = FALSE;
>  STATIC RPI_MEMORY_REGION_INFO   
> VirtualMemoryInfo[MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS];
> @@ -60,6 +60,7 @@ ArmPlatformGetVirtualMemoryMap (
>  {
>UINTN Index = 0;
>UINTN GpuIndex;
> +  INT64 OrigMemorySize;
>INT64 SystemMemorySize;
>ARM_MEMORY_REGION_DESCRIPTOR  *VirtualMemoryTable;
>
> @@ -78,7 +79,6 @@ ArmPlatformGetVirtualMemoryMap (
>  return;
>}
>
> -
>// Firmware Volume
>VirtualMemoryTable[Index].PhysicalBase= FixedPcdGet64 
> (PcdFdBaseAddress);
>VirtualMemoryTable[Index].VirtualBase = 
> VirtualMemoryTable[Index].PhysicalBase;

Drop this hunk please

> @@ -155,13 +155,13 @@ ArmPlatformGetVirtualMemoryMap (
>VirtualMemoryInfo[Index].Type = RPI_MEM_UNMAPPED_REGION;
>VirtualMemoryInfo[Index++].Name   = L"SoC Reserved (283x)";
>
> -  if (FeaturePcdGet (PcdAcpiBasicMode)) {
> -//
> -// Limit the memory to 3 GB to work around the DMA bugs in the SoC 
> without
> -// having to rely on IORT or _DMA descriptions.
> -//
> -SystemMemorySize = MIN(SystemMemorySize, 3U * SIZE_1GB);
> -  }
> +  //
> +  // By default we limit the memory to 3 GB to work around the DMA bugs in 
> the SoC, for
> +  // OSes that don't support _DMA range descriptors. On 4GB boards, it's 
> runtime
> +  // setting to boot with 4GB, and the additional 1GB is added by ConfigDxe.
> +  //
> +  OrigMemorySize = SystemMemorySize;
> +  SystemMemorySize = MIN(SystemMemorySize, 3U * SIZE_1GB);
>
>// If we have RAM above the 1 GB mark, declare it
>if (SystemMemorySize - SIZE_1GB > 0) {
> @@ -170,7 +170,20 @@ ArmPlatformGetVirtualMemoryMap (
>  VirtualMemoryTable[Index].Length= SystemMemorySize - SIZE_1GB;
>  VirtualMemoryTable[Index].Attributes= 
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
>  VirtualMemoryInfo[Index].Type   = RPI_MEM_BASIC_REGION;
> -VirtualMemoryInfo[Index++].Name = L"Extended System RAM";
> +VirtualMemoryInfo[Index++].Name = L"Extended System RAM below 
> 3GB";
> +  }
> +
> +  //
> +  // If we have RAM above 3 GB mark, declare it so it's mapped, but
> +  // don't add it to the memory map. This is done later by ConfigDxe if 
> necessary.
> +  //
> +  if (OrigMemorySize > (3UL * SIZE_1GB)) {
> +VirtualMemoryTable[Index].PhysicalBase  = 3UL * SIZE_1GB;
> +VirtualMemoryTable[Index].VirtualBase   = 
> VirtualMemoryTable[Index].PhysicalBase;
> +VirtualMemoryTable[Index].Length= OrigMemorySize - 
> VirtualMemoryTable[Index].PhysicalBase;
> +VirtualMemoryTable[Index].Attributes= 
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> +VirtualMemoryInfo[Index].Type   = RPI_MEM_UNMAPPED_REGION;
> +VirtualMemoryInfo[Index++].Name = L"Extended System RAM above 
> 3GB";
>}
>
>// End of Table
> --
> 2.21.0.windows.1
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55310): https://edk2.groups.io/g/devel/message/55310
Mute This Topic: https://groups.io/mt/71697496/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/

Re: [edk2-devel][PATCH 3/5] Platform/RPi: Make 3GB/4GB a runtime (BIOS setup) choice

[Ard Biesheuvel]

On Tue, 3 Mar 2020 at 11:33, Pete Batard  wrote:
>
> From: Andrei Warkentin 
>
> Currently some OSes (e.g FreeBSD) can make full use of the maximum
> 4 GB of RAM a Raspberry Pi 4 can offer, whereas others (e.g. Linux)
> must be restricted to only the first 3 GB.
>
> Previously this was a compile-time choice chosen by PcdAcpiBasicMode,
> and now we make it user-selectable. The default is a 3 GB limit.
>
> Signed-off-by: Pete Batard 
> ---
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 58 
> 
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  8 ++-
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni | 11 
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 41 ++
>  Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
>  Platform/RaspberryPi/RPi4/RPi4.dsc  |  6 ++
>  Platform/RaspberryPi/RaspberryPi.dec|  4 +-
>  7 files changed, 120 insertions(+), 14 deletions(-)
>
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> index 2f48ca0dd758..451a419a5358 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> @@ -11,11 +11,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -26,6 +28,8 @@ extern UINT8 ConfigDxeHiiBin[];
>  extern UINT8 ConfigDxeStrings[];
>
>  STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
> +STATIC UINT32 mModelFamily = 0;
> +STATIC UINT32 mModelInstalledMB = 0;
>
>  /*
>   * The GUID inside Platform/RaspberryPi/RPi3/AcpiTables/AcpiTables.inf and
> @@ -129,6 +133,24 @@ SetupVariables (
>  PcdSet32 (PcdCustomCpuClock, PcdGet32 (PcdCustomCpuClock));
>}
>
> +  if (mModelFamily >= 4 && mModelInstalledMB > 3 * 1024) {
> +/*
> + * This allows changing PcdRamLimitTo3GB in forms.
> + */
> +PcdSet32 (PcdRamMoreThan3GB, 1);
> +
> +Size = sizeof (UINT32);
> +Status = gRT->GetVariable (L"RamLimitTo3GB",
> +   &gConfigDxeFormSetGuid,
> +   NULL, &Size, &Var32);
> +if (EFI_ERROR (Status)) {
> +  PcdSet32 (PcdRamLimitTo3GB, PcdGet32 (PcdRamLimitTo3GB));
> +}
> +  } else {
> +PcdSet32 (PcdRamMoreThan3GB, 0);
> +PcdSet32 (PcdRamLimitTo3GB, 0);
> +  }
> +
>Size = sizeof (UINT32);
>Status = gRT->GetVariable (L"SdIsArasan",
>&gConfigDxeFormSetGuid,
> @@ -224,7 +246,6 @@ ApplyVariables (
>UINT32 CpuClock = PcdGet32 (PcdCpuClock);
>UINT32 CustomCpuClock = PcdGet32 (PcdCustomCpuClock);
>UINT32 Rate = 0;
> -  UINT32 ModelFamily = 0;
>
>if (CpuClock != 0) {
>  if (CpuClock == 2) {
> @@ -258,15 +279,18 @@ ApplyVariables (
>  DEBUG ((DEBUG_INFO, "Current CPU speed is %uHz\n", Rate));
>}
>
> -  Status = mFwProtocol->GetModelFamily (&ModelFamily);
> -  if (Status != EFI_SUCCESS) {
> -DEBUG ((DEBUG_ERROR, "Couldn't get the Raspberry Pi model family: %r\n", 
> Status));
> -  } else {
> -DEBUG ((DEBUG_INFO, "Current Raspberry Pi model family is 0x%x\n", 
> ModelFamily));
> +  if (mModelFamily >= 4 && PcdGet32 (PcdRamLimitTo3GB) == 0) {
> +Status = gDS->AddMemorySpace (EfiGcdMemoryTypeSystemMemory, BASE_1GB + 
> SIZE_2GB,
> +SIZE_1GB - (SIZE_4GB - BCM2711_SOC_REGISTERS),
> +EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT | 
> EFI_MEMORY_WB);
> +ASSERT_EFI_ERROR (Status);
> +Status = gDS->SetMemorySpaceAttributes (BASE_1GB + SIZE_2GB,
> +SIZE_1GB - (SIZE_4GB - BCM2711_SOC_REGISTERS),
> +EFI_MEMORY_WB);
> +ASSERT_EFI_ERROR (Status);
>}
>

This looks a bit hacky and ad-hoc to me.

What is

SIZE_1GB - (SIZE_4GB - BCM2711_SOC_REGISTERS),

supposed to mean? Can we declare it somewhere and document it, rather
than drop it into the middle of a function call?

> -
> -  if (ModelFamily == 3) {
> +  if (mModelFamily == 3) {
>  /*
>   * Pi 3: either Arasan or SdHost goes to SD card.
>   *
> @@ -316,7 +340,7 @@ ApplyVariables (
>  GpioPinFuncSet (52, Gpio48Group);
>  GpioPinFuncSet (53, Gpio48Group);
>
> -  } else if (ModelFamily == 4) {
> +  } else if (mModelFamily == 4) {
>  /*
>   * Pi 4: either Arasan or eMMC2 goes to SD card.
>   */
> @@ -352,7 +376,7 @@ ApplyVariables (
>GpioPinFuncSet (39, GPIO_FSEL_ALT3);
>  }
>} else {
> -DEBUG ((DEBUG_ERROR, "Model Family %d not supported...\n", ModelFamily));
> +DEBUG ((DEBUG_ERROR, "Model Family %d not supported...\n", 
> mModelFamily));
>}
>
>/*
> @@ -400,6 +424,20 @@ ConfigInitialize (
>  return Status;
>}
>
> +  Status = mFwProtocol->GetModelFamily (&mModelFamily);
> +  if (Status != EFI_SUCCESS) {
> +DEBUG ((DEBUG_ERROR, "Couldn't get the Raspberry Pi model

Re: [edk2-devel][PATCH 5/5] Platform/RPi/ConfigDxe: Improve RPi configuration forms

[Ard Biesheuvel]

On Tue, 3 Mar 2020 at 11:34, Pete Batard  wrote:
>
> Group all SD/MMC settings under the SD/MMC form.
> Make CPU settings more prominent.
> Harmonise form titles and text content.
> Reorder forms in the order they are most likely to be queried.
>
> Signed-off-by: Pete Batard 

Reviewed-by: Ard Biesheuvel 

> ---
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni | 24 +-
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 50 
> ++--
>  2 files changed, 37 insertions(+), 37 deletions(-)
>
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> index 2e79e322e558..77eda96d8136 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> @@ -14,11 +14,11 @@
>  #string STR_FORM_SET_TITLE_HELP  #language en-US "Press  to configure 
> system settings."
>
>  /*
> - * Chipset config.
> + * Chipset configuration.
>   */
>
> -#string STR_CHIPSET_FORM_TITLE  #language en-US "Chipset Configuration"
> -#string STR_CHIPSET_FORM_SUBTITLE   #language en-US "Note: OS may override 
> settings when booted."
> +#string STR_CHIPSET_FORM_TITLE  #language en-US "CPU Configuration"
> +#string STR_CHIPSET_FORM_SUBTITLE   #language en-US "Note: OS may override 
> settings."
>
>  #string STR_CHIPSET_CLOCK_CPU_PROMPT #language en-US "CPU Clock"
>  #string STR_CHIPSET_CLOCK_CPU_HELP   #language en-US "CPU Speed"
> @@ -30,11 +30,6 @@
>  #string STR_CHIPSET_CUSTOM_CPU_CLOCK_PROMPT #language en-US "CPU Clock Rate 
> (MHz)"
>  #string STR_CHIPSET_CUSTOM_CPU_CLOCK_HELP   #language en-US "Adjust the CPU 
> speed.\nMin value: 100 MHz\nMax value: 1600 MHz\n\nWarning: Overclocking can 
> make the system unbootable!"
>
> -#string STR_CHIPSET_SD_PROMPT#language en-US "uSD Routing"
> -#string STR_CHIPSET_SD_HELP  #language en-US "Choose host controller 
> to drive uSD slot"
> -#string STR_CHIPSET_SD_SDHOST#language en-US "Broadcom SDHOST"
> -#string STR_CHIPSET_SD_ARASAN#language en-US "Arasan SDHCI"
> -
>  /*
>   * Advanced configuration.
>   */
> @@ -55,8 +50,13 @@
>   * MMC/SD configuration.
>   */
>
> -#string STR_MMC_FORM_TITLE   #language en-US "SD/MMC Tweaks"
> -#string STR_MMC_FORM_SUBTITLE#language en-US "Note: UEFI only, OS will 
> override settings when booted."
> +#string STR_MMC_FORM_TITLE   #language en-US "SD/MMC Configuration"
> +#string STR_MMC_FORM_SUBTITLE#language en-US "Note: UEFI only, OS may 
> override settings."
> +
> +#string STR_MMC_SD_PROMPT#language en-US "uSD Routing"
> +#string STR_MMC_SD_HELP  #language en-US "Choose host controller to 
> drive uSD slot"
> +#string STR_MMC_SD_SDHOST#language en-US "Broadcom SDHOST"
> +#string STR_MMC_SD_ARASAN#language en-US "Arasan SDHCI"
>
>  #string STR_MMC_DISMULTI_PROMPT  #language en-US "Multi-Block Support"
>  #string STR_MMC_DISMULTI_HELP#language en-US "Use CMD18/CMD25 for 
> transfers when possible"
> @@ -84,7 +84,7 @@
>   * Display settings.
>   */
>
> -#string STR_DISPLAY_FORM_TITLE  #language en-US "Display"
> +#string STR_DISPLAY_FORM_TITLE  #language en-US "Display Configuration"
>  #string STR_DISPLAY_FORM_SUBTITLE   #language en-US "UEFI video driver 
> settings"
>
>  #string STR_DISPLAY_VMODES_640_PROMPT  #language en-US "Virtual 640x480"
> @@ -109,7 +109,7 @@
>  /*
>   * Debugging settings go here.
>   */
> -#string STR_DEBUG_FORM_TITLE#language en-US "Debugging"
> +#string STR_DEBUG_FORM_TITLE#language en-US "Debugging Configuration"
>  #string STR_DEBUG_FORM_SUBTITLE #language en-US "For UEFI/OS Developers"
>
>  #string STR_DEBUG_JTAG_PROMPT   #language en-US "JTAG Routing"
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
> index d16058da4926..9c2fd64a8e27 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
> @@ -65,14 +65,6 @@ typedef struct {
>UINT32 Clock;
>  } CHIPSET_CUSTOM_CPU_CLOCK_VARSTORE_DATA;
>
> -typedef struct {
> -  /*
> -   * 0 - uSD slot routed to Broadcom SDHOST.
> -   * 1 - uSD slot routed to Arasan SDHCI.
> -   */
> -  UINT32 Routing;
> -} CHIPSET_SD_VARSTORE_DATA;
> -
>  typedef struct {
>/*
> * Always set by ConfigDxe prior to HII init to reflect
> @@ -93,6 +85,14 @@ typedef struct {
>UINT32 Enabled;
>  } ADVANCED_DEVICE_TREE_VARSTORE_DATA;
>
> +typedef struct {
> +  /*
> +   * 0 - uSD slot routed to Broadcom SDHOST.
> +   * 1 - uSD slot routed to Arasan SDHCI.
> +   */
> +  UINT32 Routing;
> +} MMC_SD_VARSTORE_DATA;
> +
>  typedef struct {
>/*
> * 0 - Don't disable multi-block.
> @@ -155,11 +155,6 @@ formset
>name  = CustomCpuClock,
>guid  = CONFIGDXE_FORM_SET_GUID;
>
> -efivarstore CHIPSET_SD_VARSTORE_DATA,
> -  attr

Re: [edk2-devel][PATCH 4/5] Platform/RPi: Make Device Tree provision a runtime (BIOS setup) choice

[Ard Biesheuvel]

On Tue, 3 Mar 2020 at 11:33, Pete Batard  wrote:
>
> With this and the previous commit, ACPI_BASIC_MODE_ENABLE becomes
> superfluous so remove it.
>
> New option defaults to enabled on Pi 3, disabled on Pi 4.
>
> Signed-off-by: Pete Batard 

This touches a lot of different files at the same time, but I guess it
makes sense as a single set, so

Reviewed-by: Ard Biesheuvel 

> ---
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  |  8 
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 21 
> 
>  Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c|  5 +
>  Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf  |  3 +++
>  Platform/RaspberryPi/RPi3/RPi3.dsc  |  5 +
>  Platform/RaspberryPi/RPi4/RPi4.dsc  | 10 +-
>  Platform/RaspberryPi/RPi4/RPi4.fdf  |  2 --
>  Platform/RaspberryPi/RPi4/Readme.md | 15 ++
>  Platform/RaspberryPi/RaspberryPi.dec|  4 +---
>  11 files changed, 60 insertions(+), 19 deletions(-)
>
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> index 451a419a5358..31a62094e33e 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> @@ -151,6 +151,14 @@ SetupVariables (
>  PcdSet32 (PcdRamLimitTo3GB, 0);
>}
>
> +  Size = sizeof (UINT32);
> +  Status = gRT->GetVariable (L"OptDeviceTree",
> +  &gConfigDxeFormSetGuid,
> +  NULL, &Size, &Var32);
> +  if (EFI_ERROR (Status)) {
> +PcdSet32 (PcdOptDeviceTree, PcdGet32 (PcdOptDeviceTree));
> +  }
> +
>Size = sizeof (UINT32);
>Status = gRT->GetVariable (L"SdIsArasan",
>&gConfigDxeFormSetGuid,
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> index 407aac89c7b3..736d49df562b 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> @@ -72,6 +72,7 @@ [Pcd]
>gRaspberryPiTokenSpaceGuid.PcdDebugShowUEFIExit
>gRaspberryPiTokenSpaceGuid.PcdDisplayEnableScaledVModes
>gRaspberryPiTokenSpaceGuid.PcdDisplayEnableSShot
> +  gRaspberryPiTokenSpaceGuid.PcdOptDeviceTree
>gRaspberryPiTokenSpaceGuid.PcdRamMoreThan3GB
>gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
>
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> index 830533a9dc49..2e79e322e558 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> @@ -46,6 +46,11 @@
>  #string STR_ADVANCED_3GB_OFF #language en-US "Disabled"
>  #string STR_ADVANCED_3GB_ON  #language en-US "Enabled"
>
> +#string STR_ADVANCED_DT_PROMPT   #language en-US "Device Tree"
> +#string STR_ADVANCED_DT_HELP #language en-US "Disable this option to 
> force OSes such as GNU/Linux to use ACPI"
> +#string STR_ADVANCED_DT_OFF  #language en-US "Disabled (Force ACPI)"
> +#string STR_ADVANCED_DT_ON   #language en-US "Enabled"
> +
>  /*
>   * MMC/SD configuration.
>   */
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
> index 483edd7459c5..d16058da4926 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
> @@ -85,6 +85,14 @@ typedef struct {
>UINT32 Enabled;
>  } ADVANCED_RAM_LIMIT_TO_3GB_VARSTORE_DATA;
>
> +typedef struct {
> +  /*
> +   * 0 - Do not provide a Device Tree to the OS
> +   * 1 - Provide a Device Tree to the OS
> +   */
> +  UINT32 Enabled;
> +} ADVANCED_DEVICE_TREE_VARSTORE_DATA;
> +
>  typedef struct {
>/*
> * 0 - Don't disable multi-block.
> @@ -162,6 +170,11 @@ formset
>name  = RamLimitTo3GB,
>guid  = CONFIGDXE_FORM_SET_GUID;
>
> +efivarstore ADVANCED_DEVICE_TREE_VARSTORE_DATA,
> +  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
> EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
> +  name  = OptDeviceTree,
> +  guid  = CONFIGDXE_FORM_SET_GUID;
> +
>  efivarstore MMC_DISMULTI_VARSTORE_DATA,
>attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
> EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
>name  = MmcDisableMulti,
> @@ -279,6 +292,14 @@ formset
>option text = STRING_TOKEN(STR_ADVANCED_3GB_ON), value = 1, 
> flags = 0;
>endoneof;
>  endif;
> +
> +oneof varid = OptDeviceTree.Enabled,
> +prompt  = STRING_TOKEN(STR_ADVANCED_DT_PROMPT),
> +

Re: [edk2-devel] [PATCH 09/13] OvmfPkg: implement QEMU loader library for X86 with legacy fallback

[Laszlo Ersek]

On 03/03/20 11:08, Ard Biesheuvel wrote:
> On Tue, 3 Mar 2020 at 10:45, Laszlo Ersek  wrote:

>> (13) I'm worried that we are installing custom protocols on a handle
>> that was first created by LoadImage(), before we pass it to
>> UnloadImage(). I don't know if, per spec, LoadImage() / UnloadImage()
>> are allowed to associate such information with the specific image handle
>> that is *beyond* the protocol interfaces visible on the handle.
>>
> 
> I'm not sure I follow. Why would it not be allowed to install
> additional protocols on that handle? Note that it is rather common for
> drivers to install arbitrary protocols on the handle that they receive
> via the PE/COFF entry point.

Yes, that's correct; however what doesn't happen is that protocols
installed on the image handle *survive* unloading the image with
gBS->UnloadImage().

Put differently, if the image handle was created by LoadImage() -- by
virtue of LoadImage() installing the first protocol interface --, then I
*think* there might be a silent expectation that UnloadImage() will also
uninstall the last protocol interface, thereby releasing the image
handle itself.

>> Can we modify the logic somehow so that we don't have to silently call
>> QemuLoadLegacyImage() inside QemuStartKernelImage()? If not, we should
>> at least document that this is arguably a grey area per UEFI spec.
>>
> 
> That would require QemuStartImage() to take a EFI_HANDLE* rather than
> a EFI_HANDLE,

Yes, I agree.

> which is what I was trying to avoid here.

I perceive this as a lifecycle risk / grey area in the spec.

If we can make it disappear by having QemuStartImage() take an "IN OUT
EFI_HANDLE*", IMO that's a significant improvement, and hopefully not
much additional complexity. I think the underlying use case is intricate
enough for us to let it affect the abstract QemuStartKernelImage()
interface.

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55314): https://edk2.groups.io/g/devel/message/55314
Mute This Topic: https://groups.io/mt/71669022/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 12/13] OvmfPkg/QemuKernelLoaderFsDxe: add support for new Linux initrd device path

[Laszlo Ersek]

On 03/03/20 11:18, Ard Biesheuvel wrote:
> On Tue, 3 Mar 2020 at 11:10, Laszlo Ersek  wrote:
>>
>> On 03/02/20 08:29, Ard Biesheuvel wrote:
>>> Linux v5.7 will introduce a new method to load the initial ramdisk
>>> (initrd) from the loader, using the LoadFile2 protocol installed on a
>>> special vendor GUIDed media device path.
>>>
>>> Add support for this to our QEMU command line kernel/initrd loader.
>>>
>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c   | 79 
>>> 
>>>  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf |  2 +
>>>  2 files changed, 81 insertions(+)
>>>
>>> diff --git a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c 
>>> b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
>>> index 77d8fedb738a..415946edf22a 100644
>>> --- a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
>>> +++ b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
>>> @@ -13,15 +13,18 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>
>>>  //
>>> @@ -84,6 +87,19 @@ STATIC CONST SINGLE_VENMEDIA_NODE_DEVPATH 
>>> mFileSystemDevicePath = {
>>>}
>>>  };
>>>
>>> +STATIC CONST SINGLE_VENMEDIA_NODE_DEVPATH mInitrdDevicePath = {
>>> +  {
>>> +{
>>> +  MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP,
>>> +  { sizeof (VENDOR_DEVICE_PATH) }
>>> +},
>>> +LINUX_EFI_INITRD_MEDIA_GUID
>>> +  }, {
>>> +END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
>>> +{ sizeof (EFI_DEVICE_PATH_PROTOCOL) }
>>> +  }
>>> +};
>>> +
>>>  //
>>>  // The "file in the EFI stub filesystem" abstraction.
>>>  //
>>> @@ -839,6 +855,48 @@ STATIC CONST EFI_SIMPLE_FILE_SYSTEM_PROTOCOL 
>>> mFileSystem = {
>>>StubFileSystemOpenVolume
>>>  };
>>>
>>> +STATIC
>>> +EFI_STATUS
>>> +EFIAPI
>>> +InitrdLoadFile2 (
>>> +  IN EFI_LOAD_FILE2_PROTOCOL  *This,
>>> +  IN EFI_DEVICE_PATH_PROTOCOL *FilePath,
>>> +  IN BOOLEAN  BootPolicy,
>>> +  IN OUT UINTN*BufferSize,
>>> +  IN VOID *Buffer OPTIONAL
>>> +  )
>>> +{
>>> +  CONST KERNEL_BLOB   *InitrdBlob = &mKernelBlob[KernelBlobTypeInitrd];
>>> +
>>> +  ASSERT (InitrdBlob->Size > 0);
>>> +
>>> +  if (BootPolicy) {
>>> +return EFI_UNSUPPORTED;
>>> +  }
>>> +
>>> +  if (BufferSize == NULL || !IsDevicePathValid (FilePath, 0)) {
>>> +return EFI_INVALID_PARAMETER;
>>> +  }
>>> +
>>> +  if (FilePath->Type != END_DEVICE_PATH_TYPE ||
>>> +  FilePath->SubType != END_ENTIRE_DEVICE_PATH_SUBTYPE) {
>>> +return EFI_NOT_FOUND;
>>> +  }
>>> +
>>> +  if (Buffer == NULL || *BufferSize < InitrdBlob->Size) {
>>> +*BufferSize = InitrdBlob->Size;
>>> +return EFI_BUFFER_TOO_SMALL;
>>> +  }
>>> +
>>> +  CopyMem (Buffer, InitrdBlob->Data, InitrdBlob->Size);
>>> +
>>> +  *BufferSize = InitrdBlob->Size;
>>> +  return EFI_SUCCESS;
>>> +}
>>> +
>>> +STATIC CONST EFI_LOAD_FILE2_PROTOCOL mInitrdLoadFile2 = {
>>> +  InitrdLoadFile2,
>>> +};
>>>
>>>  //
>>>  // Utility functions.
>>> @@ -945,6 +1003,7 @@ QemuKernelLoaderFsDxeEntrypoint (
>>>KERNEL_BLOB   *KernelBlob;
>>>EFI_STATUSStatus;
>>>EFI_HANDLEFileSystemHandle;
>>> +  EFI_HANDLEInitrdLoadFile2Handle;
>>>
>>>if (!QemuFwCfgIsAvailable ()) {
>>>  return EFI_NOT_FOUND;
>>> @@ -989,8 +1048,28 @@ QemuKernelLoaderFsDxeEntrypoint (
>>>  goto FreeBlobs;
>>>}
>>>
>>> +  if (KernelBlob[KernelBlobTypeInitrd].Size > 0) {
>>> +InitrdLoadFile2Handle = NULL;
>>> +Status = gBS->InstallMultipleProtocolInterfaces 
>>> (&InitrdLoadFile2Handle,
>>> +&gEfiDevicePathProtocolGuid,  &mInitrdDevicePath,
>>> +&gEfiLoadFile2ProtocolGuid,   &mInitrdLoadFile2,
>>> +NULL);
>>> +if (EFI_ERROR (Status)) {
>>> +  DEBUG ((DEBUG_ERROR, "%a: InstallMultipleProtocolInterfaces(): %r\n",
>>> +__FUNCTION__, Status));
>>> +  goto UninstallFileSystemHandle;
>>> +}
>>> +  }
>>> +
>>>return EFI_SUCCESS;
>>>
>>> +UninstallFileSystemHandle:
>>> +  Status = gBS->UninstallMultipleProtocolInterfaces (FileSystemHandle,
>>> +  &gEfiDevicePathProtocolGuid,   
>>> &mFileSystemDevicePath,
>>> +  &gEfiSimpleFileSystemProtocolGuid, &mFileSystem,
>>> +  NULL);
>>> +  ASSERT_EFI_ERROR (Status);
>>> +
>>>  FreeBlobs:
>>>while (BlobType > 0) {
>>>  CurrentBlob = &mKernelBlob[--BlobType];
>>> diff --git a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf 
>>> b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
>>> index f4b50c265027..737f9b87a7c7 100644
>>> --- a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf

Re: [edk2-devel] Patch List for 202002 stable tag

[Laszlo Ersek]

On 03/03/20 09:29, Gao, Liming wrote:
> Hi, Stewards and all:
>   Below three patches status are updated. If you have no other comments, I 
> will create edk2-stable202002 tomorrow and send the announcement. 
> 
> https://edk2.groups.io/g/devel/message/55105 [PATCH 0/2] UefiCpuPkg/Library: 
> Fix bug in MpInitLib (BZ: 2556) 
> [Liming 2020-02-28] The solution is under discussion. The submitter requests 
> this issue to be fixed happen reasonably soon. So, it may not catch this 
> stable tag.
> [Liming 2020-03-03] The solution is finalized. The patch passed reviewed. 
> Now, it can catch this stable tag stable202002. The package maintainer 
> submitted it in edk2 master 4c0f6e349d32cf27a7104ddd3e729d6ebc88ea70. PR: 
> https://github.com/tianocore/edk2/pull/410

(1) Side request: please don't mix up the term "submit" with "push" or
"merge". Submit means submitting for review. "Push" or "merge" means the
patch is part of the git history.

I don't know where this mis-use of the term "submit" comes from. I've
noticed it only recently, on the list, and maybe in a few BZ comments.
It's very confusing.

(2) Actual request: TianoCore#2556 is still in UNCONFIRMED state. Just
about every aspect of that ticket is wrong:

- wrong status (should be resolved|fixed)
- wrong assignee (should be Leo, not Mike)
- the posted patch has not been referenced in a comment (into the list
archive)
- the commit hash of the resultant commit has not been noted in the BZ
(in a comment).
- the underlying issue seems like a regression on AMD platforms, from
the patch that introduced the PlatformId check. The Keywords field
should have "regression" selected, and a comment should explain what
commit exactly introduced the regression (the PlatformId check).

Leo: please fix up those problems in the BZ ticket urgently.

> 
> https://edk2.groups.io/g/devel/message/54992 [Patch 
> 1/1][edk2-stable202002]BaseTools: Fixed a regression issue in Makefile for 
> incremental build (BZ: 2563)
> [Liming 2020-02-28] This patch has passed review. This regression causes the 
> basic incremental build not work with VS nmake tool. The fix is clear. So, it 
> need to catch this stable tag.
> [Liming 2020-03-03] It is regarded as the critical fix. It was submitted in 
> edk2 master at 2be4828af1c92a848af90429a9a0b44544c80553. PR: 
> https://github.com/tianocore/edk2/pull/409

Not submitted, merged.

Otherwise, OK.

> 
> https://edk2.groups.io/g/devel/message/54995 [PATCH v1] ShellPkg: Fix 'ping' 
> command Ip4 receive flow. (BZ: 2032)
> [Liming 2020-02-28] This is the issue in ShellPkg. It may not be critical 
> issue, and defer after this stable tag.
> [Liming 2020-03-03] The submitted advised moving this issue out of CVE scope 
> (and from stable-202002). So, it will defer after this stable tag.

OK.

Maciej: if you really think this BZ (#2032) should not be in the scope
of CVE-2019-14559, then please go to
, and remove "2550"
from the "Blocks" field, after clicking "edit".

Thanks
Laszlo

> 
> Thanks
> Liming
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Leif Lindholm
> Sent: 2020年2月28日 20:48
> To: Gao, Liming 
> Cc: Laszlo Ersek ; devel@edk2.groups.io; Kinney, Michael D 
> ; af...@apple.com; Guptha, Soumya K 
> ; Marvin Häuser ; Gao, 
> Zhichao ; 'ard.biesheu...@linaro.org' 
> ; Wu, Hao A ; vit9696 
> ; gaurav.j...@nxp.com; Ni, Ray ; 
> Feng, Bob C ; maciej.rab...@linux.intel.com; 
> leo.du...@amd.com
> Subject: Re: [edk2-devel] Patch List for 202002 stable tag
> 
> On Fri, Feb 28, 2020 at 04:13:09 +, Gao, Liming wrote:
 I agree it needs to catch the stable tag. If it affects only VS 
 builds then I am not going to insist on extending the hard freeze, 
 but I (technically on holiday today/tomorrow) don't have time to 
 dig much deeper into it.

>> [Liming] This fix is to restore the original behavior before the 
>> commit 818283de3f6d for !INCLUDE style in Makefile generation. It does 
>> update GNUmakefile and VS makefile generation. Because it just 
>> restores original behavior, its quality risk is low. So, I suggest to catch 
>> it in this stable tag on current release planning.
> 
> If it is *just* a revert, then the risk is often low enough to not slip the 
> date. But I think, as you say, this is something that restores original 
> behaviour - but leaving the code different from the original.
> 
 However, I think the process is pretty clear that this *should* 
 extend the hard freeze.
>>
>> [Liming] I am not aware of the process to extend the hard freeze. But, 
>> you think more time is required for the review and test on the critical bug 
>> fix. I am OK.
>>
 I will note that from the trail (commitdate of 818283de3f6d until
 BZ2563 was raised) it appears that detecting this bug itself, 
 which went in two days before the soft freeze, took 15 days.
>>
>> [Liming] Yes. It takes 15 days to expose this issue. 
>>
>>> I agree with 

[edk2-devel] [edk2-platforms] [PATCH] IntelSiliconPkg: IOMMU generic bug fix

[De Leon Vazquez, Lorena R]

Looks like Addresswidth is BIT wise values. Right now these values are not used 
any

Suggested-by: Star Zeng star.z...@intel.com
Signed-off-by: 
lorena.r.de.leon.vazq...@intel.com

--
.../Feature/VTd/IntelVTdDxe/TranslationTable.c| 11 ---
.../Feature/VTd/IntelVTdDxe/TranslationTableEx.c  | 11 ---
2 files changed, 8 insertions(+), 14 deletions(-)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/TranslationTable.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/TranslationTable.c
index cc970c0..61fbb4a 100644
--- a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/TranslationTable.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/TranslationTable.c
@@ -128,14 +128,11 @@ CreateContextEntry (
 DEBUG ((DEBUG_INFO,"Source: S%04x B%02x D%02x F%02x\n", 
mVtdUnitInformation[VtdIndex].Segment, SourceId.Bits.Bus, SourceId.Bits.Device, 
SourceId.Bits.Function));
-switch (mVtdUnitInformation[VtdIndex].CapReg.Bits.SAGAW) {
-case BIT1:
-  ContextEntry->Bits.AddressWidth = 0x1;
-  break;
-case BIT2:
-  ContextEntry->Bits.AddressWidth = 0x2;
-  break;
+if ((mVtdUnitInformation[VtdIndex].CapReg.Bits.SAGAW & BIT2) == 0) {
+  DEBUG((DEBUG_ERROR, " 4-level page-table is not supported on VTD %d 
\n", VtdIndex));
+  return error;
 }
+ContextEntry->Bits.AddressWidth = 0x2;
   }
   FlushPageTableMemory (VtdIndex, 
(UINTN)mVtdUnitInformation[VtdIndex].RootEntryTable, 
EFI_PAGES_TO_SIZE(EntryTablePages));
diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/TranslationTableEx.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/TranslationTableEx.c
index 0da1611..6bd31b7 100644
--- a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/TranslationTableEx.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/TranslationTableEx.c
@@ -78,14 +78,11 @@ CreateExtContextEntry (
 DEBUG ((DEBUG_INFO,"DOMAIN: S%04x, B%02x D%02x F%02x\n", 
mVtdUnitInformation[VtdIndex].Segment, SourceId.Bits.Bus, SourceId.Bits.Device, 
SourceId.Bits.Function));
-switch (mVtdUnitInformation[VtdIndex].CapReg.Bits.SAGAW) {
-case BIT1:
-  ExtContextEntry->Bits.AddressWidth = 0x1;
-  break;
-case BIT2:
-  ExtContextEntry->Bits.AddressWidth = 0x2;
-  break;
+if ((mVtdUnitInformation[VtdIndex].CapReg.Bits.SAGAW & BIT2) == 0) {
+  DEBUG((DEBUG_ERROR, " 4-level page-table is not supported on VTD %d 
\n", VtdIndex));
+  return error;
 }
+ContextEntry->Bits.AddressWidth = 0x2;
   }
   FlushPageTableMemory (VtdIndex, 
(UINTN)mVtdUnitInformation[VtdIndex].ExtRootEntryTable, 
EFI_PAGES_TO_SIZE(EntryTablePages));
--
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55317): https://edk2.groups.io/g/devel/message/55317
Mute This Topic: https://groups.io/mt/71688474/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 08/42] OvmfPkg: Prepare OvmfPkg to use the VmgExitLib library

[Laszlo Ersek]

On 03/03/20 00:06, Lendacky, Thomas wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> Various CpuExceptionHandlerLib libraries will updated to use the new
> VmgExitLib library. To prevent any build breakage, update the OvmfPkg
> DSC files that use a form of the CpuExceptionHandlerLib library to
> include the VmgExitLib library.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>  OvmfPkg/OvmfPkgX64.dsc | 1 +
>  OvmfPkg/OvmfXen.dsc| 1 +
>  4 files changed, 4 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 19728f20b34e..c842404287dc 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -217,6 +217,7 @@ [LibraryClasses]
>  
>  [LibraryClasses.common]
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>  
>  [LibraryClasses.common.SEC]
>TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 3c0c229e3a72..c082617be9d8 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -222,6 +222,7 @@ [LibraryClasses]
>  
>  [LibraryClasses.common]
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>  
>  [LibraryClasses.common.SEC]
>TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index f6c1d8d228c6..d3a96e5a7be6 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -222,6 +222,7 @@ [LibraryClasses]
>  
>  [LibraryClasses.common]
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>  
>  [LibraryClasses.common.SEC]
>TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
> diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
> index 5751ff1f0352..b86129dd092a 100644
> --- a/OvmfPkg/OvmfXen.dsc
> +++ b/OvmfPkg/OvmfXen.dsc
> @@ -204,6 +204,7 @@ [LibraryClasses]
>  
>  [LibraryClasses.common]
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>  
>  [LibraryClasses.common.SEC]
>QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
> 

Reviewed-by: Laszlo Ersek 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55318): https://edk2.groups.io/g/devel/message/55318
Mute This Topic: https://groups.io/mt/71687798/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 36/42] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with SEV-ES is enabled

[Laszlo Ersek]

Hi Tom,

On 03/03/20 00:07, Lendacky, Thomas wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> The flash detection routine will attempt to determine how the flash
> device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and
> the flash device behaves as a ROM device (meaning it is marked read-only
> by the hypervisor), this check may result in an infinite nested page fault
> because of the attempted write. Since the instruction cannot be emulated
> when SEV-ES is enabled, the RIP is never advanced, resulting in repeated
> nested page faults.
> 
> When SEV-ES is enabled, exit the flash detection early and assume that
> the FD behaves as Flash. This will result in QemuFlashWrite() being called
> to store EFI variables, which will also result in an infinite nested page
> fault when the write is performed. In this case, update QemuFlashWrite()
> to use the VmgMmioWrite function from the VmgExitLib library to have the
> hypervisor perform the write without having to emulate the instruction.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc   |  1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|  1 +
>  OvmfPkg/OvmfPkgX64.dsc|  1 +

I asked for these lib class resolutions to be dropped, under v4.

53e0bc61-5105-1597-7add-86e038015e15@redhat.com">http://mid.mail-archive.com/53e0bc61-5105-1597-7add-86e038015e15@redhat.com

Laszlo

>  .../FvbServicesRuntimeDxe.inf |  2 ++
>  .../QemuFlash.h   |  6 +
>  .../QemuFlash.c   | 23 ---
>  .../QemuFlashDxe.c| 15 
>  .../QemuFlashSmm.c|  9 
>  8 files changed, 55 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 51d7acafdda3..2531b7edccf5 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -318,6 +318,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>  
>  [LibraryClasses.common.UEFI_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 764fa8c287a0..629725ef2b44 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -323,6 +323,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>  
>  [LibraryClasses.common.UEFI_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index b6e29e09db97..74076cbe7692 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -323,6 +323,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>  
>  [LibraryClasses.common.UEFI_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> index 8125fd0735a1..3ce19d1bfa8e 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> @@ -38,6 +38,7 @@ [Sources]
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> +  UefiCpuPkg/UefiCpuPkg.dec
>OvmfPkg/OvmfPkg.dec
>  
>  [LibraryClasses]
> @@ -52,6 +53,7 @@ [LibraryClasses]
>UefiBootServicesTableLib
>UefiDriverEntryPoint
>UefiRuntimeLib
> +  VmgExitLib
>  
>  [Guids]
>gEfiEventVirtualAddressChangeGuid   # ALWAYS_CONSUMED
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h 
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
> index f1afabcbe6ae..19ac1f733279 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
> @@ -89,5 +89,11 @@ QemuFlashBeforeProbe (
>IN  UINTN   FdBlockCount
>);
>  
> +VOID
> +QemuFlashPtrWrite (
> +  INvolatile UINT8*Ptr,
> +  INUINT8 Value
> +  );
> +
>  #endif
>  
> diff --git a/

[edk2-devel][PATCH v2 0/6] Platform/RPi: User config improvements

[Pete Batard]

Changes from v1:
* Split first commit into 2 patches.
* Clarify commit message for 3/6 and remove extra line-removal hunk.
* Improve and clarify computation of 3G+ segment size in
  ConfigDxe.c/ApplyVariables ().
* Minor whitespace fixes (e.g. "3GB" -> "3 GB" in strings).

Andrei Warkentin (4):
  Platform/RPi: Add firmware call to read installed memory size
  Platform/RPi: Use GetModelInstalledMB () to read RAM size
  Platform/RPi: Separate RAM descriptors between 0-3 GB and 3+ GB
  Platform/RPi: Make 3GB/4GB a runtime (BIOS setup) choice

Pete Batard (2):
  Platform/RPi: Make Device Tree provision a runtime (BIOS setup) choice
  Platform/RPi/ConfigDxe: Improve RPi configuration form

 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 80 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf   |  9 ++-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni| 38 
++---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr| 84 
+---
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c   |  5 ++
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf |  3 +
 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 10 +--
 Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c   | 29 ++-
 Platform/RaspberryPi/Include/Protocol/RpiFirmware.h| 47 
++-
 Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf   |  3 -
 Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c  | 32 
+---
 Platform/RaspberryPi/RPi3/RPi3.dsc | 11 +++
 Platform/RaspberryPi/RPi4/RPi4.dsc | 16 ++--
 Platform/RaspberryPi/RPi4/RPi4.fdf |  2 -
 Platform/RaspberryPi/RPi4/Readme.md| 15 ++--
 Platform/RaspberryPi/RaspberryPi.dec   |  6 +-
 16 files changed, 297 insertions(+), 93 deletions(-)

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55320): https://edk2.groups.io/g/devel/message/55320
Mute This Topic: https://groups.io/mt/71699468/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel][PATCH v2 2/6] Platform/RPi: Use GetModelInstalledMB () to read RAM size

[Pete Batard]

From: Andrei Warkentin 

Use the call introduced in the previous commit to read the
platform's installed memory.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 10 
--
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
index f25c439f89c8..5585cb846f41 100644
--- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
+++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -870,21 +870,19 @@ MemArrMapInfoUpdateSmbiosType19 (
   )
 {
   EFI_STATUS Status;
-  UINT32 BoardRevision = 0;
+  UINT32 InstalledMB = 0;
 
   // Note: Type 19 addresses are expressed in KB, not bytes
   // The memory layout used in all known Pi SoC's starts at 0
   mMemArrMapInfoType19.StartingAddress = 0;
+
   // The minimum RAM size used on any Raspberry Pi model is 256 MB
   mMemArrMapInfoType19.EndingAddress = 256 * 1024;
-  Status = mFwProtocol->GetModelRevision (&BoardRevision);
+  Status = mFwProtocol->GetModelInstalledMB (&InstalledMB);
   if (Status != EFI_SUCCESS) {
 DEBUG ((DEBUG_WARN, "Couldn't get the board memory size - defaulting to 
256 MB: %r\n", Status));
   } else {
-// 
www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
-// Bits [20-22] indicate the amount of memory starting with 256MB (000b)
-// and doubling in size for each value (001b = 512 MB, 010b = 1GB, etc.)
-mMemArrMapInfoType19.EndingAddress <<= (BoardRevision >> 20) & 0x07;
+mMemArrMapInfoType19.EndingAddress = InstalledMB * 1024;
   }
   mMemArrMapInfoType19.EndingAddress -= 1;
 
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55322): https://edk2.groups.io/g/devel/message/55322
Mute This Topic: https://groups.io/mt/71699473/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel][PATCH v2 6/6] Platform/RPi/ConfigDxe: Improve RPi configuration form

[Pete Batard]

Group all SD/MMC settings under the SD/MMC form.
Make CPU settings more prominent.
Harmonise form titles and text content.
Reorder forms in the order they are most likely to be queried.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni | 24 +-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 50 
++--
 2 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 2e79e322e558..77eda96d8136 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -14,11 +14,11 @@
 #string STR_FORM_SET_TITLE_HELP  #language en-US "Press  to configure 
system settings."
 
 /*
- * Chipset config.
+ * Chipset configuration.
  */
 
-#string STR_CHIPSET_FORM_TITLE  #language en-US "Chipset Configuration"
-#string STR_CHIPSET_FORM_SUBTITLE   #language en-US "Note: OS may override 
settings when booted."
+#string STR_CHIPSET_FORM_TITLE  #language en-US "CPU Configuration"
+#string STR_CHIPSET_FORM_SUBTITLE   #language en-US "Note: OS may override 
settings."
 
 #string STR_CHIPSET_CLOCK_CPU_PROMPT #language en-US "CPU Clock"
 #string STR_CHIPSET_CLOCK_CPU_HELP   #language en-US "CPU Speed"
@@ -30,11 +30,6 @@
 #string STR_CHIPSET_CUSTOM_CPU_CLOCK_PROMPT #language en-US "CPU Clock Rate 
(MHz)"
 #string STR_CHIPSET_CUSTOM_CPU_CLOCK_HELP   #language en-US "Adjust the CPU 
speed.\nMin value: 100 MHz\nMax value: 1600 MHz\n\nWarning: Overclocking can 
make the system unbootable!"
 
-#string STR_CHIPSET_SD_PROMPT#language en-US "uSD Routing"
-#string STR_CHIPSET_SD_HELP  #language en-US "Choose host controller 
to drive uSD slot"
-#string STR_CHIPSET_SD_SDHOST#language en-US "Broadcom SDHOST"
-#string STR_CHIPSET_SD_ARASAN#language en-US "Arasan SDHCI"
-
 /*
  * Advanced configuration.
  */
@@ -55,8 +50,13 @@
  * MMC/SD configuration.
  */
 
-#string STR_MMC_FORM_TITLE   #language en-US "SD/MMC Tweaks"
-#string STR_MMC_FORM_SUBTITLE#language en-US "Note: UEFI only, OS will 
override settings when booted."
+#string STR_MMC_FORM_TITLE   #language en-US "SD/MMC Configuration"
+#string STR_MMC_FORM_SUBTITLE#language en-US "Note: UEFI only, OS may 
override settings."
+
+#string STR_MMC_SD_PROMPT#language en-US "uSD Routing"
+#string STR_MMC_SD_HELP  #language en-US "Choose host controller to 
drive uSD slot"
+#string STR_MMC_SD_SDHOST#language en-US "Broadcom SDHOST"
+#string STR_MMC_SD_ARASAN#language en-US "Arasan SDHCI"
 
 #string STR_MMC_DISMULTI_PROMPT  #language en-US "Multi-Block Support"
 #string STR_MMC_DISMULTI_HELP#language en-US "Use CMD18/CMD25 for 
transfers when possible"
@@ -84,7 +84,7 @@
  * Display settings.
  */
 
-#string STR_DISPLAY_FORM_TITLE  #language en-US "Display"
+#string STR_DISPLAY_FORM_TITLE  #language en-US "Display Configuration"
 #string STR_DISPLAY_FORM_SUBTITLE   #language en-US "UEFI video driver 
settings"
 
 #string STR_DISPLAY_VMODES_640_PROMPT  #language en-US "Virtual 640x480"
@@ -109,7 +109,7 @@
 /*
  * Debugging settings go here.
  */
-#string STR_DEBUG_FORM_TITLE#language en-US "Debugging"
+#string STR_DEBUG_FORM_TITLE#language en-US "Debugging Configuration"
 #string STR_DEBUG_FORM_SUBTITLE #language en-US "For UEFI/OS Developers"
 
 #string STR_DEBUG_JTAG_PROMPT   #language en-US "JTAG Routing"
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index d16058da4926..9c2fd64a8e27 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -65,14 +65,6 @@ typedef struct {
   UINT32 Clock;
 } CHIPSET_CUSTOM_CPU_CLOCK_VARSTORE_DATA;
 
-typedef struct {
-  /*
-   * 0 - uSD slot routed to Broadcom SDHOST.
-   * 1 - uSD slot routed to Arasan SDHCI.
-   */
-  UINT32 Routing;
-} CHIPSET_SD_VARSTORE_DATA;
-
 typedef struct {
   /*
* Always set by ConfigDxe prior to HII init to reflect
@@ -93,6 +85,14 @@ typedef struct {
   UINT32 Enabled;
 } ADVANCED_DEVICE_TREE_VARSTORE_DATA;
 
+typedef struct {
+  /*
+   * 0 - uSD slot routed to Broadcom SDHOST.
+   * 1 - uSD slot routed to Arasan SDHCI.
+   */
+  UINT32 Routing;
+} MMC_SD_VARSTORE_DATA;
+
 typedef struct {
   /*
* 0 - Don't disable multi-block.
@@ -155,11 +155,6 @@ formset
   name  = CustomCpuClock,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
-efivarstore CHIPSET_SD_VARSTORE_DATA,
-  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
-  name  = SdIsArasan,
-  guid  = CONFIGDXE_FORM_SET_GUID;
-
 efivarstore ADVANCED_RAM_MORE_THAN_3GB_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VA

[edk2-devel][PATCH v2 5/6] Platform/RPi: Make Device Tree provision a runtime (BIOS setup) choice

[Pete Batard]

With this and the previous commit, ACPI_BASIC_MODE_ENABLE becomes
superfluous so remove it.

New option defaults to enabled on Pi 3, disabled on Pi 4.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  |  8 
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 21 

 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c|  5 +
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf  |  3 +++
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  5 +
 Platform/RaspberryPi/RPi4/RPi4.dsc  | 10 +-
 Platform/RaspberryPi/RPi4/RPi4.fdf  |  2 --
 Platform/RaspberryPi/RPi4/Readme.md | 15 ++
 Platform/RaspberryPi/RaspberryPi.dec|  4 +---
 11 files changed, 60 insertions(+), 19 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 964ca6d369da..ccac8daad402 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -151,6 +151,14 @@ SetupVariables (
 PcdSet32 (PcdRamLimitTo3GB, 0);
   }
 
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"OptDeviceTree",
+  &gConfigDxeFormSetGuid,
+  NULL, &Size, &Var32);
+  if (EFI_ERROR (Status)) {
+PcdSet32 (PcdOptDeviceTree, PcdGet32 (PcdOptDeviceTree));
+  }
+
   Size = sizeof (UINT32);
   Status = gRT->GetVariable (L"SdIsArasan",
   &gConfigDxeFormSetGuid,
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index 407aac89c7b3..736d49df562b 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -72,6 +72,7 @@ [Pcd]
   gRaspberryPiTokenSpaceGuid.PcdDebugShowUEFIExit
   gRaspberryPiTokenSpaceGuid.PcdDisplayEnableScaledVModes
   gRaspberryPiTokenSpaceGuid.PcdDisplayEnableSShot
+  gRaspberryPiTokenSpaceGuid.PcdOptDeviceTree
   gRaspberryPiTokenSpaceGuid.PcdRamMoreThan3GB
   gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 830533a9dc49..2e79e322e558 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -46,6 +46,11 @@
 #string STR_ADVANCED_3GB_OFF #language en-US "Disabled"
 #string STR_ADVANCED_3GB_ON  #language en-US "Enabled"
 
+#string STR_ADVANCED_DT_PROMPT   #language en-US "Device Tree"
+#string STR_ADVANCED_DT_HELP #language en-US "Disable this option to 
force OSes such as GNU/Linux to use ACPI"
+#string STR_ADVANCED_DT_OFF  #language en-US "Disabled (Force ACPI)"
+#string STR_ADVANCED_DT_ON   #language en-US "Enabled"
+
 /*
  * MMC/SD configuration.
  */
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index 483edd7459c5..d16058da4926 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -85,6 +85,14 @@ typedef struct {
   UINT32 Enabled;
 } ADVANCED_RAM_LIMIT_TO_3GB_VARSTORE_DATA;
 
+typedef struct {
+  /*
+   * 0 - Do not provide a Device Tree to the OS
+   * 1 - Provide a Device Tree to the OS
+   */
+  UINT32 Enabled;
+} ADVANCED_DEVICE_TREE_VARSTORE_DATA;
+
 typedef struct {
   /*
* 0 - Don't disable multi-block.
@@ -162,6 +170,11 @@ formset
   name  = RamLimitTo3GB,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
+efivarstore ADVANCED_DEVICE_TREE_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = OptDeviceTree,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore MMC_DISMULTI_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = MmcDisableMulti,
@@ -279,6 +292,14 @@ formset
   option text = STRING_TOKEN(STR_ADVANCED_3GB_ON), value = 1, 
flags = 0;
   endoneof;
 endif;
+
+oneof varid = OptDeviceTree.Enabled,
+prompt  = STRING_TOKEN(STR_ADVANCED_DT_PROMPT),
+help= STRING_TOKEN(STR_ADVANCED_DT_HELP),
+flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+option text = STRING_TOKEN(STR_ADVANCED_DT_OFF), value = 0, flags 
= 0;
+option text = STRING_TOKEN(STR_ADVANCED_DT_ON), value = 1, flags = 
DEFAULT;
+endoneof;
 endform;
 
 form formid = 0x1003,
diff --git a/Platform/RaspberryPi/Drivers/

[edk2-devel][PATCH v2 4/6] Platform/RPi: Make 3GB/4GB a runtime (BIOS setup) choice

[Pete Batard]

From: Andrei Warkentin 

Currently some OSes (e.g FreeBSD) can make full use of the maximum
4 GB of RAM a Raspberry Pi 4 can offer, whereas others (e.g. Linux)
must be restricted to only the first 3 GB.

Previously this was a compile-time choice chosen by PcdAcpiBasicMode,
and now we make it user-selectable. The default is a 3 GB limit.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 72 
+---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  8 ++-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni | 11 +++
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 41 +++
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc  |  6 ++
 Platform/RaspberryPi/RaspberryPi.dec|  4 +-
 7 files changed, 134 insertions(+), 14 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 2f48ca0dd758..964ca6d369da 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -11,11 +11,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +28,8 @@ extern UINT8 ConfigDxeHiiBin[];
 extern UINT8 ConfigDxeStrings[];
 
 STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
+STATIC UINT32 mModelFamily = 0;
+STATIC UINT32 mModelInstalledMB = 0;
 
 /*
  * The GUID inside Platform/RaspberryPi/RPi3/AcpiTables/AcpiTables.inf and
@@ -129,6 +133,24 @@ SetupVariables (
 PcdSet32 (PcdCustomCpuClock, PcdGet32 (PcdCustomCpuClock));
   }
 
+  if (mModelFamily >= 4 && mModelInstalledMB > 3 * 1024) {
+/*
+ * This allows changing PcdRamLimitTo3GB in forms.
+ */
+PcdSet32 (PcdRamMoreThan3GB, 1);
+
+Size = sizeof (UINT32);
+Status = gRT->GetVariable (L"RamLimitTo3GB",
+   &gConfigDxeFormSetGuid,
+   NULL, &Size, &Var32);
+if (EFI_ERROR (Status)) {
+  PcdSet32 (PcdRamLimitTo3GB, PcdGet32 (PcdRamLimitTo3GB));
+}
+  } else {
+PcdSet32 (PcdRamMoreThan3GB, 0);
+PcdSet32 (PcdRamLimitTo3GB, 0);
+  }
+
   Size = sizeof (UINT32);
   Status = gRT->GetVariable (L"SdIsArasan",
   &gConfigDxeFormSetGuid,
@@ -224,7 +246,7 @@ ApplyVariables (
   UINT32 CpuClock = PcdGet32 (PcdCpuClock);
   UINT32 CustomCpuClock = PcdGet32 (PcdCustomCpuClock);
   UINT32 Rate = 0;
-  UINT32 ModelFamily = 0;
+  UINT64 SystemMemorySize;
 
   if (CpuClock != 0) {
 if (CpuClock == 2) {
@@ -258,15 +280,31 @@ ApplyVariables (
 DEBUG ((DEBUG_INFO, "Current CPU speed is %uHz\n", Rate));
   }
 
-  Status = mFwProtocol->GetModelFamily (&ModelFamily);
-  if (Status != EFI_SUCCESS) {
-DEBUG ((DEBUG_ERROR, "Couldn't get the Raspberry Pi model family: %r\n", 
Status));
-  } else {
-DEBUG ((DEBUG_INFO, "Current Raspberry Pi model family is 0x%x\n", 
ModelFamily));
+  if (mModelFamily >= 4 && PcdGet32 (PcdRamLimitTo3GB) == 0) {
+/*
+ * Similar to how we compute the > 3 GB RAM segment's size in PlatformLib/
+ * RaspberryPiMem.c, with some overlap protection for the Bcm2xxx register
+ * spaces. This computation should also work for models with more than 4 GB
+ * RAM, if there ever exist ones.
+ */
+SystemMemorySize = (UINT64)mModelInstalledMB * SIZE_1MB;
+ASSERT (SystemMemorySize > 3UL * SIZE_1GB);
+SystemMemorySize = MIN(SystemMemorySize, BCM2836_SOC_REGISTERS);
+if (BCM2711_SOC_REGISTERS > 0) {
+  SystemMemorySize = MIN(SystemMemorySize, BCM2711_SOC_REGISTERS);
+}
+
+Status = gDS->AddMemorySpace (EfiGcdMemoryTypeSystemMemory, 3UL * BASE_1GB,
+SystemMemorySize - (3UL * SIZE_1GB),
+EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT | 
EFI_MEMORY_WB);
+ASSERT_EFI_ERROR (Status);
+Status = gDS->SetMemorySpaceAttributes (3UL * BASE_1GB,
+SystemMemorySize - (3UL * SIZE_1GB),
+EFI_MEMORY_WB);
+ASSERT_EFI_ERROR (Status);
   }
 
-
-  if (ModelFamily == 3) {
+  if (mModelFamily == 3) {
 /*
  * Pi 3: either Arasan or SdHost goes to SD card.
  *
@@ -316,7 +354,7 @@ ApplyVariables (
 GpioPinFuncSet (52, Gpio48Group);
 GpioPinFuncSet (53, Gpio48Group);
 
-  } else if (ModelFamily == 4) {
+  } else if (mModelFamily == 4) {
 /*
  * Pi 4: either Arasan or eMMC2 goes to SD card.
  */
@@ -352,7 +390,7 @@ ApplyVariables (
   GpioPinFuncSet (39, GPIO_FSEL_ALT3);
 }
   } else {
-DEBUG ((DEBUG_ERROR, "Model Family %d not supported...\n", ModelFamily));
+DEBUG ((DEBUG_ERROR, "Model Family %d not supported...\n", mModelFamily));
   }
 
   /*
@@ -400,6 +438,20 @@ ConfigInitialize (
 return Status;
   }
 
+  Status = mFwProtocol->GetModelFamily (&mModelFamily);
+  if (Status != EFI_SUCCESS) 

[edk2-devel][PATCH v2 1/6] Platform/RPi: Add firmware call to read installed memory size

[Pete Batard]

From: Andrei Warkentin 

Add a new RPiFirmwareGetModelInstalledMB () call in RpiFirmwareDxe
to return the amount of detected installed RAM on the system (in MB).

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 29 +++-
 Platform/RaspberryPi/Include/Protocol/RpiFirmware.h  | 47 
+++-
 2 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
index 75826fdc0e53..40c78b5d57cf 100644
--- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
+++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -606,6 +606,32 @@ RpiFirmwareGetModelName (
   }
 }
 
+STATIC
+EFI_STATUS
+EFIAPI
+RPiFirmwareGetModelInstalledMB (
+  OUT   UINT32 *InstalledMB
+  )
+{
+  EFI_STATUS Status;
+  UINT32 Revision;
+
+  Status = RpiFirmwareGetModelRevision(&Revision);
+  if (EFI_ERROR(Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Could not get the board revision: Status == 
%r\n",
+  __FUNCTION__, Status));
+return EFI_DEVICE_ERROR;
+  }
+
+  //
+  // 
www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
+  // Bits [20-22] indicate the amount of memory starting with 256MB (000b)
+  // and doubling in size for each value (001b = 512 MB, 010b = 1GB, etc.)
+  //
+  *InstalledMB = 256 << ((Revision >> 20) & 0x07);
+  return EFI_SUCCESS;
+}
+
 STATIC
 EFI_STATUS
 EFIAPI
@@ -1236,7 +1262,8 @@ STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL 
mRpiFirmwareProtocol = {
   RpiFirmwareGetFirmwareRevision,
   RpiFirmwareGetManufacturerName,
   RpiFirmwareGetCpuName,
-  RpiFirmwareGetArmMemory
+  RpiFirmwareGetArmMemory,
+  RPiFirmwareGetModelInstalledMB,
 };
 
 /**
diff --git a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h 
b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
index e3287e3c040f..108becbd3b6d 100644
--- a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
+++ b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
@@ -115,6 +115,12 @@ EFI_STATUS
   UINT32 *Revision
   );
 
+typedef
+EFI_STATUS
+(EFIAPI *GET_MODEL_INSTALLED_MB) (
+  UINT32 *InstalledMB
+  );
+
 typedef
 CHAR8*
 (EFIAPI *GET_MANUFACTURER_NAME) (
@@ -135,26 +141,27 @@ EFI_STATUS
   );
 
 typedef struct {
-  SET_POWER_STATE   SetPowerState;
-  GET_MAC_ADDRESS   GetMacAddress;
-  GET_COMMAND_LINE  GetCommandLine;
-  GET_CLOCK_RATEGetClockRate;
-  GET_CLOCK_RATEGetMaxClockRate;
-  GET_CLOCK_RATEGetMinClockRate;
-  SET_CLOCK_RATESetClockRate;
-  GET_FBGetFB;
-  FREE_FB   FreeFB;
-  GET_FB_SIZE   GetFBSize;
-  SET_LED   SetLed;
-  GET_SERIALGetSerial;
-  GET_MODEL GetModel;
-  GET_MODEL_REVISIONGetModelRevision;
-  GET_MODEL_NAMEGetModelName;
-  GET_MODEL_FAMILY  GetModelFamily;
-  GET_FIRMWARE_REVISION GetFirmwareRevision;
-  GET_MANUFACTURER_NAME GetManufacturerName;
-  GET_CPU_NAME  GetCpuName;
-  GET_ARM_MEM   GetArmMem;
+  SET_POWER_STATESetPowerState;
+  GET_MAC_ADDRESSGetMacAddress;
+  GET_COMMAND_LINE   GetCommandLine;
+  GET_CLOCK_RATE GetClockRate;
+  GET_CLOCK_RATE GetMaxClockRate;
+  GET_CLOCK_RATE GetMinClockRate;
+  SET_CLOCK_RATE SetClockRate;
+  GET_FB GetFB;
+  FREE_FBFreeFB;
+  GET_FB_SIZEGetFBSize;
+  SET_LEDSetLed;
+  GET_SERIAL GetSerial;
+  GET_MODEL  GetModel;
+  GET_MODEL_REVISION GetModelRevision;
+  GET_MODEL_NAME GetModelName;
+  GET_MODEL_FAMILY   GetModelFamily;
+  GET_FIRMWARE_REVISION  GetFirmwareRevision;
+  GET_MANUFACTURER_NAME  GetManufacturerName;
+  GET_CPU_NAME   GetCpuName;
+  GET_ARM_MEMGetArmMem;
+  GET_MODEL_INSTALLED_MB GetModelInstalledMB;
 } RASPBERRY_PI_FIRMWARE_PROTOCOL;
 
 extern EFI_GUID gRaspberryPiFirmwareProtocolGuid;
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55321): https://edk2.groups.io/g/devel/message/55321
Mute This Topic: https://groups.io/mt/71699472/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel][PATCH v2 3/6] Platform/RPi: Separate RAM descriptors between 0-3 GB and 3+ GB

[Pete Batard]

From: Andrei Warkentin 

Splitting the RAM descriptors is required so that we can make the 3 to 4 GB
segment of the Raspberry Pi 4 a user-configurable option.

This also removes the need for the PcdAcpiBasicMode PCD.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf  |  3 --
 Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c | 32 
++--
 2 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf 
b/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf
index 9abcc2cc0075..77cdbe399a06 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf
+++ b/Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf
@@ -59,8 +59,5 @@ [FixedPcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
 
-[FeaturePcd]
-  gRaspberryPiTokenSpaceGuid.PcdAcpiBasicMode
-
 [Ppis]
   gArmMpCoreInfoPpiGuid
diff --git a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c 
b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
index 4b388465cdde..901e5e3ee924 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
+++ b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
@@ -25,7 +25,7 @@ UINT32 mBoardRevision;
 
 
 // The total number of descriptors, including the final "end-of-table" 
descriptor.
-#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 10
+#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 11
 
 STATIC BOOLEAN  VirtualMemoryInfoInitialized = FALSE;
 STATIC RPI_MEMORY_REGION_INFO   
VirtualMemoryInfo[MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS];
@@ -60,6 +60,7 @@ ArmPlatformGetVirtualMemoryMap (
 {
   UINTN Index = 0;
   UINTN GpuIndex;
+  INT64 OrigMemorySize;
   INT64 SystemMemorySize;
   ARM_MEMORY_REGION_DESCRIPTOR  *VirtualMemoryTable;
 
@@ -155,13 +156,13 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryInfo[Index].Type = RPI_MEM_UNMAPPED_REGION;
   VirtualMemoryInfo[Index++].Name   = L"SoC Reserved (283x)";
 
-  if (FeaturePcdGet (PcdAcpiBasicMode)) {
-//
-// Limit the memory to 3 GB to work around the DMA bugs in the SoC without
-// having to rely on IORT or _DMA descriptions.
-//
-SystemMemorySize = MIN(SystemMemorySize, 3U * SIZE_1GB);
-  }
+  //
+  // By default we limit the memory to 3 GB to work around the DMA bugs in the 
SoC,
+  // for OSes that don't support _DMA range descriptors. On 4GB boards, it's 
runtime
+  // setting to boot with 4 GB, and the additional 1 GB is added by ConfigDxe.
+  //
+  OrigMemorySize = SystemMemorySize;
+  SystemMemorySize = MIN(SystemMemorySize, 3UL * SIZE_1GB);
 
   // If we have RAM above the 1 GB mark, declare it
   if (SystemMemorySize - SIZE_1GB > 0) {
@@ -170,7 +171,20 @@ ArmPlatformGetVirtualMemoryMap (
 VirtualMemoryTable[Index].Length= SystemMemorySize - SIZE_1GB;
 VirtualMemoryTable[Index].Attributes= 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
 VirtualMemoryInfo[Index].Type   = RPI_MEM_BASIC_REGION;
-VirtualMemoryInfo[Index++].Name = L"Extended System RAM";
+VirtualMemoryInfo[Index++].Name = L"Extended System RAM below 3 
GB";
+  }
+
+  //
+  // If we have RAM above 3 GB mark, declare it so it's mapped, but
+  // don't add it to the memory map. This is done later by ConfigDxe if 
necessary.
+  //
+  if (OrigMemorySize > (3UL * SIZE_1GB)) {
+VirtualMemoryTable[Index].PhysicalBase  = 3UL * SIZE_1GB;
+VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
+VirtualMemoryTable[Index].Length= OrigMemorySize - 
VirtualMemoryTable[Index].PhysicalBase;
+VirtualMemoryTable[Index].Attributes= 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
+VirtualMemoryInfo[Index].Type   = RPI_MEM_UNMAPPED_REGION;
+VirtualMemoryInfo[Index++].Name = L"Extended System RAM above 3 
GB";
   }
 
   // End of Table
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55323): https://edk2.groups.io/g/devel/message/55323
Mute This Topic: https://groups.io/mt/71699475/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 34/42] OvmfPkg/Sec: Add #VC exception handling for Sec phase

[Laszlo Ersek]

Hi Tom,

On 03/03/20 00:07, Lendacky, Thomas wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> An SEV-ES guest will generate a #VC exception when it encounters a
> non-automatic exit (NAE) event. It is expected that the #VC exception
> handler will communicate with the hypervisor using the GHCB to handle
> the NAE event.
> 
> NAE events can occur during the Sec phase, so initialize exception
> handling early in the OVMF Sec support.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Reviewed-by: Laszlo Ersek 

this patch has changed significantly since the last version (v4); I
think my R-b given for v4 should not have been picked up in v5.

AFAICS the new stuff is SevEsProtocolFailure() and SevEsProtocolCheck(),
which -- per v5 blurb -- have moved from UefiCpuPkg to OvmfPkg:


> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/Sec/SecMain.inf |   4 ++
>  OvmfPkg/Sec/SecMain.c   | 151 
>  2 files changed, 142 insertions(+), 13 deletions(-)
> 
> diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
> index 63ba4cb555fb..7f78dcee2772 100644
> --- a/OvmfPkg/Sec/SecMain.inf
> +++ b/OvmfPkg/Sec/SecMain.inf
> @@ -50,15 +50,19 @@ [LibraryClasses]
>PeCoffExtraActionLib
>ExtractGuidedSectionLib
>LocalApicLib
> +  CpuExceptionHandlerLib
>  
>  [Ppis]
>gEfiTemporaryRamSupportPpiGuid# PPI ALWAYS_PRODUCED
>  
>  [Pcd]
> +  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
> index bae9764577f0..577596a949f9 100644
> --- a/OvmfPkg/Sec/SecMain.c
> +++ b/OvmfPkg/Sec/SecMain.c
> @@ -24,6 +24,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
>  
> @@ -34,6 +37,10 @@ typedef struct _SEC_IDT_TABLE {
>IA32_IDT_GATE_DESCRIPTOR  IdtTable[SEC_IDT_ENTRY_COUNT];
>  } SEC_IDT_TABLE;
>  
> +typedef struct _SEC_SEV_ES_WORK_AREA {
> +  UINT8  SevEsEnabled;
> +} SEC_SEV_ES_WORK_AREA;
> +
>  VOID
>  EFIAPI
>  SecStartupPhase2 (
> @@ -712,6 +719,90 @@ FindAndReportEntryPoints (
>return;
>  }
>  
> +STATIC
> +VOID
> +SevEsProtocolFailure (
> +  IN UINT8  ReasonCode
> +  )
> +{
> +  MSR_SEV_ES_GHCB_REGISTER  Msr;
> +
> +  //
> +  // Use the GHCB MSR Protocol to request termination by the hypervisor
> +  //
> +  Msr.GhcbPhysicalAddress = 0;
> +  Msr.GhcbTerminate.Function = GHCB_INFO_TERMINATE_REQUEST;
> +  Msr.GhcbTerminate.ReasonCodeSet = GHCB_TERMINATE_GHCB;
> +  Msr.GhcbTerminate.ReasonCode = ReasonCode;
> +  AsmWriteMsr64 (MSR_SEV_ES_GHCB, Msr.GhcbPhysicalAddress);
> +
> +  AsmVmgExit ();
> +
> +  ASSERT (0);

(1) The argument should be FALSE, not 0.

> +  CpuDeadLoop ();
> +}
> +
> +STATIC
> +VOID
> +SevEsProtocolCheck (
> +  VOID
> +  )
> +{
> +  MSR_SEV_ES_GHCB_REGISTER  Msr;
> +  GHCB  *Ghcb;
> +
> +  //
> +  // Use the GHCB MSR Protocol to obtain the GHCB SEV-ES Information for
> +  // protocol checking
> +  //
> +  Msr.GhcbPhysicalAddress = 0;
> +  Msr.GhcbInfo.Function = GHCB_INFO_SEV_INFO_GET;
> +  AsmWriteMsr64 (MSR_SEV_ES_GHCB, Msr.GhcbPhysicalAddress);
> +
> +  AsmVmgExit ();
> +
> +  Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
> +
> +  if (Msr.GhcbInfo.Function != GHCB_INFO_SEV_INFO) {
> +SevEsProtocolFailure (GHCB_TERMINATE_GHCB_GENERAL);
> +  }
> +
> +  if (Msr.GhcbProtocol.SevEsProtocolMin > Msr.GhcbProtocol.SevEsProtocolMax) 
> {
> +SevEsProtocolFailure (GHCB_TERMINATE_GHCB_PROTOCOL);
> +  }
> +
> +  if ((Msr.GhcbProtocol.SevEsProtocolMin > GHCB_VERSION_MAX) ||
> +  (Msr.GhcbProtocol.SevEsProtocolMax < GHCB_VERSION_MIN)) {
> +SevEsProtocolFailure (GHCB_TERMINATE_GHCB_PROTOCOL);
> +  }
> +
> +  //
> +  // SEV-ES protocol checking succeeded, set the initial GHCB address
> +  //
> +  Msr.GhcbPhysicalAddress = FixedPcdGet32 (PcdOvmfSecGhcbBase);
> +  AsmWriteMsr64(MSR_SEV_ES_GHCB, Msr.GhcbPhysicalAddress);
> +
> +  Ghcb = Msr.Ghcb;
> +  SetMem (Ghcb, sizeof (*Ghcb), 0);
> +
> +  /* Set the version to the maximum that can be supported */

(2) The comment style is not consistent with the rest.

With the style warts (1) and (2) fixed:

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> +  Ghcb->ProtocolVersion = MIN (Msr.GhcbProtocol.SevEsProtocolMax, 
> GHCB_VERSION_MAX);
> +  Ghcb->GhcbUsage = GHCB_STANDARD_USAGE;
> +}
> +
> +STATIC
> +BOOLEAN
> +SevEsIsEnabled (
> +  VOID
> +  )
> +{
> +  SEC_SEV_ES_WORK_AREA  *SevEsWorkArea;
> +
> +  SevEsWorkArea = (SEC_SEV_ES_WORK_AREA *) FixedPcdGe

[edk2-devel] [PATCH v4 7/7] OvmfPkg/LinuxInitrdDynamicShellCommand: bail if initrd already exists

[Ard Biesheuvel]

Before taking any actions, check if an instance of the LoadFile2 exists
already on the Linux initrd media GUID device path, and whether it was
provided by this command. If so, abort, since no duplicate instances of
the device path should exist.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel 
---
 OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c   | 31 

 OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni |  3 
++
 2 files changed, 34 insertions(+)

diff --git 
a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c 
b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
index 47ed26b50d3a..ed8fbaa77069 100644
--- a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
+++ b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
@@ -53,6 +53,33 @@ STATIC CONST SINGLE_NODE_VENDOR_MEDIA_DEVPATH 
mInitrdDevicePath = {
   }
 };
 
+STATIC
+BOOLEAN
+IsOtherInitrdDevicePathAlreadyInstalled (
+  VOID
+  )
+{
+  EFI_STATUS  Status;
+  EFI_DEVICE_PATH_PROTOCOL*DevicePath;
+  EFI_HANDLE  Handle;
+
+  DevicePath = (EFI_DEVICE_PATH_PROTOCOL *)&mInitrdDevicePath;
+  Status = gBS->LocateDevicePath (&gEfiLoadFile2ProtocolGuid, &DevicePath,
+  &Handle);
+  if (EFI_ERROR (Status)) {
+return FALSE;
+  }
+
+  //
+  // Check whether the existing instance is one that we installed during
+  // a previous invocation.
+  //
+  if (Handle == mInitrdLoadFile2Handle) {
+return FALSE;
+  }
+  return TRUE;
+}
+
 STATIC
 EFI_STATUS
 EFIAPI
@@ -217,6 +244,10 @@ RunInitrd (
 } else {
   ASSERT(FALSE);
 }
+  } else if (IsOtherInitrdDevicePathAlreadyInstalled ()) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ALREADY_INSTALLED),
+  mLinuxInitrdShellCommandHiiHandle, L"initrd");
+ShellStatus = SHELL_UNSUPPORTED;
   } else {
 if (ShellCommandLineGetCount (Package) > 2) {
   ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_TOO_MANY),
diff --git 
a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni 
b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
index a88fa6e3641b..4b6b1285fffd 100644
--- a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
+++ b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
@@ -18,6 +18,7 @@
 #langdef   en-US "english"
 
 #string STR_GEN_PROBLEM   #language en-US "%H%s%N: Unknown flag - 
'%H%s%N'\r\n"
+#string STR_GEN_ALREADY_INSTALLED #language en-US "%H%s%N: Linux initrd 
already provided by platform\r\n"
 #string STR_GEN_TOO_MANY  #language en-US "%H%s%N: Too many 
arguments.\r\n"
 #string STR_GEN_TOO_FEW   #language en-US "%H%s%N: Too few 
arguments.\r\n"
 #string STR_GEN_FIND_FAIL #language en-US "%H%s%N: File not found - 
'%H%s%N'\r\n"
@@ -47,3 +48,5 @@
 " Consumers of the LoadFile2 protocol on the 
LINUX_EFI_INITRD_MEDIA_GUID\r\n"
 " device path that are started via means other than the shell will be 
able\r\n"
 " to locate the protocol and invoke it.\r\n"
+"  3. Exposing an initrd using this command is only supported if no initrd 
is\r\n"
+" already being exposed by another driver on the platform.\r\n"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55335): https://edk2.groups.io/g/devel/message/55335
Mute This Topic: https://groups.io/mt/71700589/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 6/7] OvmfPkg IA32: add support for loading X64 images

[Ard Biesheuvel]

This is the UEFI counterpart to my Linux series which generalizes
mixed mode support into a feature that requires very little internal
knowledge about the architecture specifics of booting Linux on the
part of the bootloader or firmware.

Instead, we add a .compat PE/COFF header containing an array of
PE_COMPAT nodes containing  tuples that
describe alternate entrypoints into the image for different native
machine types, e.g., IA-32 in a 64-bit image so it can be booted
from IA-32 firmware.

This patch implements the PE/COFF emulator protocol to take this new
section into account, so that such images can simply be loaded via
LoadImage/StartImage, e.g., straight from the shell.

This feature is based on the EDK2 specific PE/COFF emulator protocol
that was introduced in commit 57df17fe26cd ("MdeModulePkg/DxeCore:
invoke the emulator protocol for foreign images", 2019-04-14).

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
---
 OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c   | 143 

 OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.inf |  37 +
 OvmfPkg/OvmfPkgIa32.dsc   |   5 +
 OvmfPkg/OvmfPkgIa32.fdf   |   4 +
 4 files changed, 189 insertions(+)

diff --git a/OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c 
b/OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c
new file mode 100644
index ..ae47917f1589
--- /dev/null
+++ b/OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c
@@ -0,0 +1,143 @@
+/** @file
+ *  PE/COFF emulator protocol implementation to start Linux kernel
+ *  images from non-native firmware
+ *
+ *  Copyright (c) 2020, ARM Ltd. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#pragma pack (1)
+typedef struct {
+  UINT8   Type;
+  UINT8   Size;
+  UINT16  MachineType;
+  UINT32  EntryPoint;
+} PE_COMPAT_TYPE1;
+#pragma pack ()
+
+STATIC
+BOOLEAN
+EFIAPI
+IsImageSupported (
+  IN  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
+  IN  UINT16  ImageType,
+  IN  EFI_DEVICE_PATH_PROTOCOL*DevicePath   OPTIONAL
+  )
+{
+  return ImageType == EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION;
+}
+
+STATIC
+EFI_IMAGE_ENTRY_POINT
+EFIAPI
+GetCompatEntryPoint (
+  IN  EFI_PHYSICAL_ADDRESS  ImageBase
+  )
+{
+  EFI_IMAGE_DOS_HEADER  *DosHdr;
+  UINTN PeCoffHeaderOffset;
+  EFI_IMAGE_NT_HEADERS32*Pe32;
+  EFI_IMAGE_SECTION_HEADER  *Section;
+  UINTN NumberOfSections;
+  PE_COMPAT_TYPE1   *PeCompat;
+  VOID  *PeCompatEnd;
+
+  DosHdr = (EFI_IMAGE_DOS_HEADER *)(UINTN)ImageBase;
+  if (DosHdr->e_magic != EFI_IMAGE_DOS_SIGNATURE) {
+return NULL;
+  }
+
+  PeCoffHeaderOffset = DosHdr->e_lfanew;
+  Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN)ImageBase + PeCoffHeaderOffset);
+
+  Section = (EFI_IMAGE_SECTION_HEADER *)((UINTN)&Pe32->OptionalHeader +
+ 
Pe32->FileHeader.SizeOfOptionalHeader);
+  NumberOfSections = (UINTN)Pe32->FileHeader.NumberOfSections;
+
+  while (NumberOfSections--) {
+if (!CompareMem (Section->Name, ".compat", sizeof (Section->Name))) {
+  //
+  // Dereference the section contents to find the mixed mode entry point
+  //
+  PeCompat = (PE_COMPAT_TYPE1 *)((UINTN)ImageBase + 
Section->VirtualAddress);
+  PeCompatEnd = (UINT8 *)PeCompat + Section->Misc.VirtualSize;
+
+  while (PeCompat->Type != 0 && (VOID *)PeCompat < PeCompatEnd) {
+if (PeCompat->Type == 1 &&
+PeCompat->Size >= sizeof (PE_COMPAT_TYPE1) &&
+EFI_IMAGE_MACHINE_TYPE_SUPPORTED (PeCompat->MachineType)) {
+
+  return (EFI_IMAGE_ENTRY_POINT)((UINTN)ImageBase + 
PeCompat->EntryPoint);
+}
+PeCompat = (PE_COMPAT_TYPE1 *)((UINTN)PeCompat + PeCompat->Size);
+ASSERT ((VOID *)PeCompat < PeCompatEnd);
+  }
+}
+Section++;
+  }
+  return NULL;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+RegisterImage (
+  IN  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
+  IN  EFI_PHYSICAL_ADDRESSImageBase,
+  IN  UINT64  ImageSize,
+  IN  OUT EFI_IMAGE_ENTRY_POINT   *EntryPoint
+  )
+{
+  EFI_IMAGE_ENTRY_POINT   CompatEntryPoint;
+
+  CompatEntryPoint = GetCompatEntryPoint (ImageBase);
+  if (CompatEntryPoint == NULL) {
+return EFI_UNSUPPORTED;
+  }
+
+  *EntryPoint = CompatEntryPoint;
+  return EFI_SUCCESS;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+UnregisterImage (
+  IN  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
+  IN  EFI_PHYSICAL_ADDRESSImageBase
+  )
+{
+  return EFI_SUCCESS;
+}
+
+STATIC EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL m

[edk2-devel] [PATCH v4 0/7] OvmfPkg: implement initrd shell command and mixed mode loader

[Ard Biesheuvel]

This series is part of my effort to define a generic EFI boot protocol for
Linux, i.e,. one that is the same across all different architectures that
are able to boot Linux from EFI, and naturally reused the firmware's
infrastructure for authenticated boot and measured boot.

Path #1 ... #4 implement the 'initrd' dynamic shell command, which takes a
file and exposes it via the LoadFile2 protocol installed on a vendor media
device path with guid LINUX_EFI_INITRD_MEDIA_GUID. This is a Linux specific,
but arch-agnostic way for the OS loader to load an initial ramdisk, while
leaving the firmware (or bootloader) in charge of where the file contents
are served from. This supersedes the currently existing solutions on Linux,
which are either limited to loading from the same volume that the OS loader
was loaded from, or load the initrd into memory first, and use architecture
specific data structures to pass on the information regarding base and size.

Patch #5 is an update to the integration of the PE/COFF emulator protocol,
to align it more closely with how LoadImage() and StartImage() behave today:
LoadImage() is not restricted to images that can execute natively on the
platform, but also permits loading of cross-type supported images. This means
that any judgement on whether an image can be *started* needs to be deferred
until StartImage(), which is why the invocation of the RegisterImage()
callback needs to be deferred as well.

Patch #6 implements the PE/COFF emulator protocol so it can start X64 images
that have been loaded on IA32 firmware. This is needed for Linux's so-called
'mixed mode', which is an elaborate scheme of on-the-fly translation of data
structures and thunking into 32-bit compat mode, allowing X64 Linux kernels
to be used on X64 capable hardware that shipped with IA32 firmware. This
needs support from the loader, and is currently implemented in GRUB (and
OVMF's command line kernel loader) using the EFI handover protocol, which
relies far too much on knowledge of kernel internal data structures, and
circumvents LoadImage and StartImage entirely.
(Note: mixed mode support is mainly targeted at cheap Atom tablets that
shipped with a [cheaper] 32-bit version of Windows, and so this particular
patch is unlikely to help that use case, but it is useful for validation.)

Patch #7 is new in v4, and modified the initrd Shell command so it aborts
immediately if the Linux initrd media GUID device path already has the
LoadFile2 protocol installed in the protocol database.

With these changes in place, we can boot x86 mixed-mode Linux straight from
the UEFI Shell

Shell>initrd fs0:\initrd.img
Shell>fs0:\bzImage root=/dev/vda2

Another benefit of this approach is that we can exit cleanly from the loader
(and back to the shell) using the Exit() boot service if any errors occur,
whereas the EFI handover protocol enters a deadloop upon any error that
occurs during execution of the EFI stub.

Changes since v3:
- pick up some acks
- update patch #6 to sanity check the contents of the .compat section so
  we don't overrun the end of the section looking for a compatible entrypoint
- add patch #7

Changes since v2:
- incorporate Laszlo's feedback, and add R-b's - I have incorporated all the
  feedback given, except for the structure of the shell command implementation:
  it is not my preferred style, but it is correct, and idiomatic for the shell
  commands I could find in the tree.

Changes from v1:
- Use a dynamic UEFI shell command, which is the recommended way of implementing
  new shell commands that are not covered by the UEFI shell specification. It
  also makes the command more easily usable on existing platforms, since the
  driver can be loaded as an ordinary driver.
- split initrd patch into 4, as requested by Laszlo
- add patch to tweak the LoadImage/StartImage behavior wrt the PE/COFF emulator
  protocol
- return EFI_UNSUPPORTED from PeCoffEmu::RegisterImage() if the image does not
  have the required .compat section

[0] https://edk2.groups.io/g/devel/topic/rfc_patch_1_1_ovmfpkg_add/71177416
[1] https://edk2.groups.io/g/devel/topic/patch_1_1_ovmfpkg_ia32_add/71272266

v2: https://edk2.groups.io/g/devel/topic/patch_v2_0_6_ovmfpkg/71530294
v3: https://edk2.groups.io/g/devel/message/54932

Cc: ler...@redhat.com
Cc: l...@nuviainc.com
Cc: Liming Gao 

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564

Ard Biesheuvel (7):
  OvmfPkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
  OvmfPkg: add 'initrd' shell command to expose Linux initrd via device
path
  ArmVirtPkg: add the 'initrd' dynamic shell command
  OvmfPkg: add the 'initrd' dynamic shell command
  MdeModulePkg/DxeCore: defer PE/COFF emulator registration to
StartImage
  OvmfPkg IA32: add support for loading X64 images
  OvmfPkg/LinuxInitrdDynamicShellCommand: bail if initrd already exists

 ArmVirtPkg/ArmVirt.dsc.inc|   4 +
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc  |   1 +
 ArmVirtPkg/ArmVirtXen.fdf  

[edk2-devel] [PATCH v4 1/7] OvmfPkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID

[Ard Biesheuvel]

Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions,
it can be used in a media device path to specify a Linux style initrd
that can be loaded by the OS using the LoadFile2 protocol.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h | 17 +
 OvmfPkg/OvmfPkg.dec|  1 +
 2 files changed, 18 insertions(+)

diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h 
b/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
new file mode 100644
index ..83fc3fc79aa6
--- /dev/null
+++ b/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
@@ -0,0 +1,17 @@
+/** @file
+  GUID definition for the Linux Initrd media device path
+
+  Copyright (c) 2020, Arm, Ltd. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef LINUX_EFI_INITRD_MEDIA_GUID_H__
+#define LINUX_EFI_INITRD_MEDIA_GUID_H__
+
+#define LINUX_EFI_INITRD_MEDIA_GUID \
+  {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 
0x68}}
+
+extern EFI_GUID gLinuxEfiInitrdMediaGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 4c5b6511cb97..6849a79cd8b0 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -86,6 +86,7 @@ [Guids]
   gMicrosoftVendorGuid= {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 
0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}}
   gEfiLegacyBiosGuid  = {0x2E3044AC, 0x879F, 0x490F, {0x97, 
0x60, 0xBB, 0xDF, 0xAF, 0x69, 0x5F, 0x50}}
   gEfiLegacyDevOrderVariableGuid  = {0xa56074db, 0x65fe, 0x45f7, {0xbd, 
0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96, 0x52}}
+  gLinuxEfiInitrdMediaGuid= {0x5568e427, 0x68fc, 0x4f3d, {0xac, 
0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}}
 
 [Protocols]
   gVirtioDeviceProtocolGuid   = {0xfa920010, 0x6785, 0x4941, {0xb6, 
0xec, 0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55329): https://edk2.groups.io/g/devel/message/55329
Mute This Topic: https://groups.io/mt/71700581/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 2/7] OvmfPkg: add 'initrd' shell command to expose Linux initrd via device path

[Ard Biesheuvel]

Add a new 'initrd' command to the UEFI Shell that allows any file that is
accessible to the shell to be registered as the initrd that is returned
when Linux's EFI stub loader invokes the LoadFile2 protocol on its special
vendor media device path.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c   | 
429 
 OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf |  
53 +++
 OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni |  
49 +++
 3 files changed, 531 insertions(+)

diff --git 
a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c 
b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
new file mode 100644
index ..47ed26b50d3a
--- /dev/null
+++ b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
@@ -0,0 +1,429 @@
+/** @file
+  Provides 'initrd' dynamic UEFI shell command to load a Linux initrd
+  via its GUIDed vendor media path
+
+  Copyright (c) 2020, Arm, Ltd. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#pragma pack (1)
+typedef struct {
+  VENDOR_DEVICE_PATH  VenMediaNode;
+  EFI_DEVICE_PATH_PROTOCOLEndNode;
+} SINGLE_NODE_VENDOR_MEDIA_DEVPATH;
+#pragma pack ()
+
+STATIC EFI_HII_HANDLE mLinuxInitrdShellCommandHiiHandle;
+STATIC EFI_PHYSICAL_ADDRESS   mInitrdFileAddress;
+STATIC UINTN  mInitrdFileSize;
+STATIC EFI_HANDLE mInitrdLoadFile2Handle;
+
+STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
+  {L"-u", TypeFlag},
+  {NULL, TypeMax}
+  };
+
+STATIC CONST SINGLE_NODE_VENDOR_MEDIA_DEVPATH mInitrdDevicePath = {
+  {
+{
+  MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP, { sizeof (VENDOR_DEVICE_PATH) }
+},
+LINUX_EFI_INITRD_MEDIA_GUID
+  }, {
+END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+{ sizeof (EFI_DEVICE_PATH_PROTOCOL) }
+  }
+};
+
+STATIC
+EFI_STATUS
+EFIAPI
+InitrdLoadFile2 (
+  IN  EFI_LOAD_FILE2_PROTOCOL   *This,
+  IN  EFI_DEVICE_PATH_PROTOCOL  *FilePath,
+  IN  BOOLEAN   BootPolicy,
+  IN  OUT UINTN *BufferSize,
+  OUT VOID  *Buffer OPTIONAL
+  )
+{
+  if (BootPolicy) {
+return EFI_UNSUPPORTED;
+  }
+
+  if (BufferSize == NULL || !IsDevicePathValid (FilePath, 0)) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (FilePath->Type != END_DEVICE_PATH_TYPE ||
+  FilePath->SubType != END_ENTIRE_DEVICE_PATH_SUBTYPE ||
+  mInitrdFileSize == 0) {
+return EFI_NOT_FOUND;
+  }
+
+  if (Buffer == NULL || *BufferSize < mInitrdFileSize) {
+*BufferSize = mInitrdFileSize;
+return EFI_BUFFER_TOO_SMALL;
+  }
+
+  ASSERT (mInitrdFileAddress != 0);
+
+  gBS->CopyMem (Buffer, (VOID *)(UINTN)mInitrdFileAddress, mInitrdFileSize);
+  *BufferSize = mInitrdFileSize;
+  return EFI_SUCCESS;
+}
+
+STATIC CONST EFI_LOAD_FILE2_PROTOCOL mInitrdLoadFile2 = {
+  InitrdLoadFile2,
+};
+
+STATIC
+EFI_STATUS
+UninstallLoadFile2Protocol (
+  VOID
+  )
+{
+  EFI_STATUSStatus;
+
+  if (mInitrdLoadFile2Handle != NULL) {
+Status = gBS->UninstallMultipleProtocolInterfaces (mInitrdLoadFile2Handle,
+&gEfiDevicePathProtocolGuid,&mInitrdDevicePath,
+&gEfiLoadFile2ProtocolGuid, &mInitrdLoadFile2,
+NULL);
+if (!EFI_ERROR (Status)) {
+  mInitrdLoadFile2Handle = NULL;
+}
+  }
+  return Status;
+}
+
+STATIC
+VOID
+FreeInitrdFile (
+  VOID
+  )
+{
+  if (mInitrdFileSize != 0) {
+gBS->FreePages (mInitrdFileAddress, EFI_SIZE_TO_PAGES (mInitrdFileSize));
+mInitrdFileSize = 0;
+  }
+}
+
+STATIC
+EFI_STATUS
+CacheInitrdFile (
+  IN  SHELL_FILE_HANDLE   FileHandle
+  )
+{
+  EFI_STATUS  Status;
+  UINT64  FileSize;
+  UINTN   ReadSize;
+
+  Status = gEfiShellProtocol->GetFileSize (FileHandle, &FileSize);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  if (FileSize == 0 || FileSize > MAX_UINTN) {
+return EFI_UNSUPPORTED;
+  }
+
+  Status = gBS->AllocatePages (AllocateAnyPages, EfiLoaderData,
+  EFI_SIZE_TO_PAGES ((UINTN)FileSize), &mInitrdFileAddress);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  ReadSize = (UINTN)FileSize;
+  Status = gEfiShellProtocol->ReadFile (FileHandle, &ReadSize,
+(VOID *)(UINTN)mInitrdFileAddress);
+  if (EFI_ERROR (Status) || ReadSize < FileSize) {
+DEBUG ((DEBUG_WARN, "%a: failed to read initrd file - %r 0x%lx 0x%lx\n",
+  __FUNCTION__, Status, (UINT64)ReadSize, FileSize));
+goto FreeMemory;
+  }
+
+  if (mInitrdLoadFile2Handle == NULL) {
+Status = gBS->In

[edk2-devel] [PATCH v4 5/7] MdeModulePkg/DxeCore: defer PE/COFF emulator registration to StartImage

[Ard Biesheuvel]

EDK2's implementation of the LoadImage() boot service permits non-native
binaries to be loaded (i.e., X64 images on IA32 firmware), but any
attempts to start such an image using StartImage() will return
EFI_UNSUPPORTED.

The integration of the PE/COFF emulator protocol into the DXE core
deviates slightly from this paradigm, given that its IsImageSupported
hook as well as its RegisterImage hook are invoked from LoadImage,
and by the time StartImage is called, no opportunity is given to the
provider of the PE/COFF emulator protocol to prevent an image from
being started if it only supports loading it.

To address this disparity, let's move the invocation of RegisterImage()
to the implementation of the StartImage() boot service, allowing the
emulator to permit LoadImage() but reject StartImage() on images that
turn out not to meet the requirements of the emulator as it is being
started.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel 
Acked-by: Liming Gao 
---
 MdeModulePkg/Core/Dxe/Image/Image.c | 24 +++-
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Image/Image.c 
b/MdeModulePkg/Core/Dxe/Image/Image.c
index 22a87ecf6d7c..d86da89ee704 100644
--- a/MdeModulePkg/Core/Dxe/Image/Image.c
+++ b/MdeModulePkg/Core/Dxe/Image/Image.c
@@ -756,17 +756,6 @@ CoreLoadPeImage (
   // Get the image entry point.
   //
   Image->EntryPoint   = 
(EFI_IMAGE_ENTRY_POINT)(UINTN)Image->ImageContext.EntryPoint;
-  if (Image->PeCoffEmu != NULL) {
-Status = Image->PeCoffEmu->RegisterImage (Image->PeCoffEmu,
- Image->ImageBasePage,
- EFI_PAGES_TO_SIZE (Image->NumberOfPages),
- &Image->EntryPoint);
-if (EFI_ERROR (Status)) {
-  DEBUG ((DEBUG_LOAD | DEBUG_ERROR,
-"CoreLoadPeImage: Failed to register foreign image with emulator.\n"));
-  goto Done;
-}
-  }
 
   //
   // Fill in the image information for the Loaded Image Protocol
@@ -1603,6 +1592,19 @@ CoreStartImage (
 return EFI_UNSUPPORTED;
   }
 
+  if (Image->PeCoffEmu != NULL) {
+Status = Image->PeCoffEmu->RegisterImage (Image->PeCoffEmu,
+ Image->ImageBasePage,
+ EFI_PAGES_TO_SIZE (Image->NumberOfPages),
+ &Image->EntryPoint);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_LOAD | DEBUG_ERROR,
+"CoreLoadPeImage: Failed to register foreign image with emulator - 
%r\n",
+  Status));
+  return Status;
+}
+  }
+
   PERF_START_IMAGE_BEGIN (Handle);
 
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55333): https://edk2.groups.io/g/devel/message/55333
Mute This Topic: https://groups.io/mt/71700587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 3/7] ArmVirtPkg: add the 'initrd' dynamic shell command

[Ard Biesheuvel]

Add the 'initrd' dynamic shell command to the build so we can load
Linux initrds straight from the shell using the new generic protocol,
which does not rely on initrd= being passed on the command line.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
---
 ArmVirtPkg/ArmVirt.dsc.inc   | 4 
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
 ArmVirtPkg/ArmVirtXen.fdf| 1 +
 3 files changed, 6 insertions(+)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 10037c938eb8..42ecd5ce1d52 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -379,6 +379,10 @@ [Components.common]
 
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   }
+  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
   ShellPkg/Application/Shell/Shell.inf {
 
   
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index 31f615a9d0f9..bfa380815f1a 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -103,6 +103,7 @@ [FV.FvMain]
   #
   INF ShellPkg/Application/Shell/Shell.inf
   INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
+  INF OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
 
   #
   # Bds
diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
index 38d4cc163524..6a97bceeacbc 100644
--- a/ArmVirtPkg/ArmVirtXen.fdf
+++ b/ArmVirtPkg/ArmVirtXen.fdf
@@ -182,6 +182,7 @@ [FV.FvMain]
   #
   INF ShellPkg/Application/Shell/Shell.inf
   INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
+  INF OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
 
   #
   # Bds
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55331): https://edk2.groups.io/g/devel/message/55331
Mute This Topic: https://groups.io/mt/71700583/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 4/7] OvmfPkg: add the 'initrd' dynamic shell command

[Ard Biesheuvel]

Add the 'initrd' dynamic shell command to the build so we can load
Linux initrds straight from the shell using the new generic protocol,
which does not rely on initrd= being passed on the command line.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 4 
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 4 
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 4 
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 OvmfPkg/OvmfXen.dsc| 4 
 OvmfPkg/OvmfXen.fdf| 1 +
 8 files changed, 20 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 19728f20b34e..76e52a3de120 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -821,6 +821,10 @@ [Components]
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   }
 !endif
+  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
   ShellPkg/Application/Shell/Shell.inf {
 
   
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 63607551ed75..6c342823d206 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -281,6 +281,7 @@ [FV.DXEFV]
 !if $(TOOL_CHAIN_TAG) != "XCODE5"
 INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
 !endif
+INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
 INF  ShellPkg/Application/Shell/Shell.inf
 
 INF MdeModulePkg/Logo/LogoDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 3c0c229e3a72..842b4a028913 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -834,6 +834,10 @@ [Components.X64]
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   }
 !endif
+  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
   ShellPkg/Application/Shell/Shell.inf {
 
   
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 0488e5d95ffe..69c133ec08d5 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -282,6 +282,7 @@ [FV.DXEFV]
 !if $(TOOL_CHAIN_TAG) != "XCODE5"
 INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
 !endif
+INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
 INF  ShellPkg/Application/Shell/Shell.inf
 
 INF MdeModulePkg/Logo/LogoDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index f6c1d8d228c6..0b1e45d1f15a 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -832,6 +832,10 @@ [Components]
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   }
 !endif
+  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
   ShellPkg/Application/Shell/Shell.inf {
 
   
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 0488e5d95ffe..69c133ec08d5 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -282,6 +282,7 @@ [FV.DXEFV]
 !if $(TOOL_CHAIN_TAG) != "XCODE5"
 INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
 !endif
+INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
 INF  ShellPkg/Application/Shell/Shell.inf
 
 INF MdeModulePkg/Logo/LogoDxe.inf
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 5751ff1f0352..d476694b18d5 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -692,6 +692,10 @@ [Components]
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   }
 !endif
+  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
   ShellPkg/Application/Shell/Shell.inf {
 
   
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 05138ffc5b4f..5ca8081c0265 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -364,6 +364,7 @@ [FV.DXEFV]
 !if $(TOOL_CHAIN_TAG) != "XCODE5"
 INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
 !endif
+INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
 INF  ShellPkg/Application/Shell/Shell.inf
 
 INF MdeModulePkg/Logo/LogoDxe.inf
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55332): https://edk2.groups.io/g/devel/message/55332
Mute This Topic: https://groups.io/mt/71700585/21656
Group O

Re: [edk2-devel][PATCH v2 0/6] Platform/RPi: User config improvements

[Ard Biesheuvel]

On Tue, 3 Mar 2020 at 14:08, Pete Batard  wrote:
>
> Changes from v1:
> * Split first commit into 2 patches.
> * Clarify commit message for 3/6 and remove extra line-removal hunk.
> * Improve and clarify computation of 3G+ segment size in
>   ConfigDxe.c/ApplyVariables ().
> * Minor whitespace fixes (e.g. "3GB" -> "3 GB" in strings).
>
> Andrei Warkentin (4):
>   Platform/RPi: Add firmware call to read installed memory size
>   Platform/RPi: Use GetModelInstalledMB () to read RAM size
>   Platform/RPi: Separate RAM descriptors between 0-3 GB and 3+ GB
>   Platform/RPi: Make 3GB/4GB a runtime (BIOS setup) choice
>
> Pete Batard (2):
>   Platform/RPi: Make Device Tree provision a runtime (BIOS setup) choice
>   Platform/RPi/ConfigDxe: Improve RPi configuration form

Reviewed-by: Ard Biesheuvel 

Pushed as d5f7c68948a3..dac18ca51781

Thanks!

>
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 80 
> ---
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf   |  9 ++-
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni| 38 
> ++---
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr| 84 
> +---
>  Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c   |  5 ++
>  Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf |  3 +
>  Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 10 +--
>  Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c   | 29 
> ++-
>  Platform/RaspberryPi/Include/Protocol/RpiFirmware.h| 47 
> ++-
>  Platform/RaspberryPi/Library/PlatformLib/PlatformLib.inf   |  3 -
>  Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c  | 32 
> +---
>  Platform/RaspberryPi/RPi3/RPi3.dsc | 11 +++
>  Platform/RaspberryPi/RPi4/RPi4.dsc | 16 ++--
>  Platform/RaspberryPi/RPi4/RPi4.fdf |  2 -
>  Platform/RaspberryPi/RPi4/Readme.md| 15 ++--
>  Platform/RaspberryPi/RaspberryPi.dec   |  6 +-
>  16 files changed, 297 insertions(+), 93 deletions(-)
>
> --
> 2.21.0.windows.1
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55336): https://edk2.groups.io/g/devel/message/55336
Mute This Topic: https://groups.io/mt/71699468/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 34/42] OvmfPkg/Sec: Add #VC exception handling for Sec phase

[Lendacky, Thomas]

On 3/3/20 7:29 AM, Laszlo Ersek wrote:
> Hi Tom,
> 
> On 03/03/20 00:07, Lendacky, Thomas wrote:
>> BZ: 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2198&data=02%7C01%7Cthomas.lendacky%40amd.com%7C3fd18aafb8934669131408d7bf76e70a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637188389716613512&sdata=uGe95zCVx0egVqiWYDqpAeS3k5aO5ZU6eHiyx8fpKxo%3D&reserved=0
>>
>> An SEV-ES guest will generate a #VC exception when it encounters a
>> non-automatic exit (NAE) event. It is expected that the #VC exception
>> handler will communicate with the hypervisor using the GHCB to handle
>> the NAE event.
>>
>> NAE events can occur during the Sec phase, so initialize exception
>> handling early in the OVMF Sec support.
>>
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Reviewed-by: Laszlo Ersek 
> 
> this patch has changed significantly since the last version (v4); I
> think my R-b given for v4 should not have been picked up in v5.

Sorry about that, missed that when I made this change.

> 
> AFAICS the new stuff is SevEsProtocolFailure() and SevEsProtocolCheck(),
> which -- per v5 blurb -- have moved from UefiCpuPkg to OvmfPkg:

Correct.

> 
> 
>> Signed-off-by: Tom Lendacky 
>> ---
>>  OvmfPkg/Sec/SecMain.inf |   4 ++
>>  OvmfPkg/Sec/SecMain.c   | 151 
>>  2 files changed, 142 insertions(+), 13 deletions(-)
>>
>> diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
>> index 63ba4cb555fb..7f78dcee2772 100644
>> --- a/OvmfPkg/Sec/SecMain.inf
>> +++ b/OvmfPkg/Sec/SecMain.inf
>> @@ -50,15 +50,19 @@ [LibraryClasses]
>>PeCoffExtraActionLib
>>ExtractGuidedSectionLib
>>LocalApicLib
>> +  CpuExceptionHandlerLib
>>  
>>  [Ppis]
>>gEfiTemporaryRamSupportPpiGuid# PPI ALWAYS_PRODUCED
>>  
>>  [Pcd]
>> +  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
>> index bae9764577f0..577596a949f9 100644
>> --- a/OvmfPkg/Sec/SecMain.c
>> +++ b/OvmfPkg/Sec/SecMain.c
>> @@ -24,6 +24,9 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>> +#include 
>>  
>>  #include 
>>  
>> @@ -34,6 +37,10 @@ typedef struct _SEC_IDT_TABLE {
>>IA32_IDT_GATE_DESCRIPTOR  IdtTable[SEC_IDT_ENTRY_COUNT];
>>  } SEC_IDT_TABLE;
>>  
>> +typedef struct _SEC_SEV_ES_WORK_AREA {
>> +  UINT8  SevEsEnabled;
>> +} SEC_SEV_ES_WORK_AREA;
>> +
>>  VOID
>>  EFIAPI
>>  SecStartupPhase2 (
>> @@ -712,6 +719,90 @@ FindAndReportEntryPoints (
>>return;
>>  }
>>  
>> +STATIC
>> +VOID
>> +SevEsProtocolFailure (
>> +  IN UINT8  ReasonCode
>> +  )
>> +{
>> +  MSR_SEV_ES_GHCB_REGISTER  Msr;
>> +
>> +  //
>> +  // Use the GHCB MSR Protocol to request termination by the hypervisor
>> +  //
>> +  Msr.GhcbPhysicalAddress = 0;
>> +  Msr.GhcbTerminate.Function = GHCB_INFO_TERMINATE_REQUEST;
>> +  Msr.GhcbTerminate.ReasonCodeSet = GHCB_TERMINATE_GHCB;
>> +  Msr.GhcbTerminate.ReasonCode = ReasonCode;
>> +  AsmWriteMsr64 (MSR_SEV_ES_GHCB, Msr.GhcbPhysicalAddress);
>> +
>> +  AsmVmgExit ();
>> +
>> +  ASSERT (0);
> 
> (1) The argument should be FALSE, not 0.

Will fix.

> 
>> +  CpuDeadLoop ();
>> +}
>> +
>> +STATIC
>> +VOID
>> +SevEsProtocolCheck (
>> +  VOID
>> +  )
>> +{
>> +  MSR_SEV_ES_GHCB_REGISTER  Msr;
>> +  GHCB  *Ghcb;
>> +
>> +  //
>> +  // Use the GHCB MSR Protocol to obtain the GHCB SEV-ES Information for
>> +  // protocol checking
>> +  //
>> +  Msr.GhcbPhysicalAddress = 0;
>> +  Msr.GhcbInfo.Function = GHCB_INFO_SEV_INFO_GET;
>> +  AsmWriteMsr64 (MSR_SEV_ES_GHCB, Msr.GhcbPhysicalAddress);
>> +
>> +  AsmVmgExit ();
>> +
>> +  Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
>> +
>> +  if (Msr.GhcbInfo.Function != GHCB_INFO_SEV_INFO) {
>> +SevEsProtocolFailure (GHCB_TERMINATE_GHCB_GENERAL);
>> +  }
>> +
>> +  if (Msr.GhcbProtocol.SevEsProtocolMin > 
>> Msr.GhcbProtocol.SevEsProtocolMax) {
>> +SevEsProtocolFailure (GHCB_TERMINATE_GHCB_PROTOCOL);
>> +  }
>> +
>> +  if ((Msr.GhcbProtocol.SevEsProtocolMin > GHCB_VERSION_MAX) ||
>> +  (Msr.GhcbProtocol.SevEsProtocolMax < GHCB_VERSION_MIN)) {
>> +SevEsProtocolFailure (GHCB_TERMINATE_GHCB_PROTOCOL);
>> +  }
>> +
>> +  //
>> +  // SEV-ES protocol checking succeeded, set the initial GHCB address
>> +  //
>> +  Msr.GhcbPhysicalAddress = FixedPcdGet32 (PcdOvmfSecGhcbBase);
>> +  AsmWriteMsr64(MSR_SEV_ES_GHCB, Msr.GhcbPhysicalAddress);
>> +
>> +  Ghcb = Msr.Ghcb;
>> + 

Re: [edk2-devel] [PATCH v5 36/42] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with SEV-ES is enabled

[Lendacky, Thomas]

On 3/3/20 6:33 AM, Laszlo Ersek wrote:
> Hi Tom,
> 
> On 03/03/20 00:07, Lendacky, Thomas wrote:
>> BZ: 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2198&data=02%7C01%7Cthomas.lendacky%40amd.com%7Cec51d6f2d119454bdbc508d7bf6f127a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637188356100831031&sdata=h7GUpHnIH8kilQY9wvXwvIujG6YU5PgYl5wYK2rP2Eg%3D&reserved=0
>>
>> The flash detection routine will attempt to determine how the flash
>> device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and
>> the flash device behaves as a ROM device (meaning it is marked read-only
>> by the hypervisor), this check may result in an infinite nested page fault
>> because of the attempted write. Since the instruction cannot be emulated
>> when SEV-ES is enabled, the RIP is never advanced, resulting in repeated
>> nested page faults.
>>
>> When SEV-ES is enabled, exit the flash detection early and assume that
>> the FD behaves as Flash. This will result in QemuFlashWrite() being called
>> to store EFI variables, which will also result in an infinite nested page
>> fault when the write is performed. In this case, update QemuFlashWrite()
>> to use the VmgMmioWrite function from the VmgExitLib library to have the
>> hypervisor perform the write without having to emulate the instruction.
>>
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Reviewed-by: Laszlo Ersek 
>> Signed-off-by: Tom Lendacky 
>> ---
>>  OvmfPkg/OvmfPkgIa32.dsc   |  1 +
>>  OvmfPkg/OvmfPkgIa32X64.dsc|  1 +
>>  OvmfPkg/OvmfPkgX64.dsc|  1 +
> 
> I asked for these lib class resolutions to be dropped, under v4.

Hmmm... I thought I had when I consolidated the library references, but
obviously I didn't. I'll fix that up.

Thanks,
Tom

> 
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmid.mail-archive.com%2F53e0bc61-5105-1597-7add-86e038015e15%40redhat.com&data=02%7C01%7Cthomas.lendacky%40amd.com%7Cec51d6f2d119454bdbc508d7bf6f127a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637188356100841024&sdata=QrbXlgrKDVhspRRKaXPUSaD5KJ5u7vZ9q6yQ70SKSWM%3D&reserved=0
> 
> Laszlo
> 
>>  .../FvbServicesRuntimeDxe.inf |  2 ++
>>  .../QemuFlash.h   |  6 +
>>  .../QemuFlash.c   | 23 ---
>>  .../QemuFlashDxe.c| 15 
>>  .../QemuFlashSmm.c|  9 
>>  8 files changed, 55 insertions(+), 3 deletions(-)
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>> index 51d7acafdda3..2531b7edccf5 100644
>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>> @@ -318,6 +318,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
>> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>>  
>>  [LibraryClasses.common.UEFI_DRIVER]
>>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>> index 764fa8c287a0..629725ef2b44 100644
>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>> @@ -323,6 +323,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
>> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>>  
>>  [LibraryClasses.common.UEFI_DRIVER]
>>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>> index b6e29e09db97..74076cbe7692 100644
>> --- a/OvmfPkg/OvmfPkgX64.dsc
>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>> @@ -323,6 +323,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
>> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>>  
>>  [LibraryClasses.common.UEFI_DRIVER]
>>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>> diff --git 
>> a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
>> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
>> index 8125fd0735a1..3ce19d1bfa8e 100644
>> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
>> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
>> @@ -38,6 +38,7 @@ [Sources]
>>  [Packages]
>>MdePkg/MdePkg.dec
>>MdeModulePkg/MdeModulePkg.dec
>> +  UefiCpuPkg/UefiCpuPkg.dec
>>OvmfPkg/OvmfPkg.dec
>>  
>> 

Re: [edk2-devel][PATCH v2 6/6] Platform/RPi/ConfigDxe: Improve RPi configuration form

[Andrei Warkentin via Groups.Io]

Reviewed-by: Andrei Warkentin 


From: Pete Batard 
Sent: Tuesday, March 3, 2020 8:08 AM
To: devel@edk2.groups.io
Cc: ard.biesheu...@linaro.org; l...@nuviainc.com; phi...@redhat.com; Andrei 
Warkentin
Subject: [edk2-devel][PATCH v2 6/6] Platform/RPi/ConfigDxe: Improve RPi 
configuration form

Group all SD/MMC settings under the SD/MMC form.
Make CPU settings more prominent.
Harmonise form titles and text content.
Reorder forms in the order they are most likely to be queried.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni | 24 +-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 50 
++--
 2 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 2e79e322e558..77eda96d8136 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -14,11 +14,11 @@
 #string STR_FORM_SET_TITLE_HELP  #language en-US "Press  to configure 
system settings."

 /*
- * Chipset config.
+ * Chipset configuration.
  */

-#string STR_CHIPSET_FORM_TITLE  #language en-US "Chipset Configuration"
-#string STR_CHIPSET_FORM_SUBTITLE   #language en-US "Note: OS may override 
settings when booted."
+#string STR_CHIPSET_FORM_TITLE  #language en-US "CPU Configuration"
+#string STR_CHIPSET_FORM_SUBTITLE   #language en-US "Note: OS may override 
settings."

 #string STR_CHIPSET_CLOCK_CPU_PROMPT #language en-US "CPU Clock"
 #string STR_CHIPSET_CLOCK_CPU_HELP   #language en-US "CPU Speed"
@@ -30,11 +30,6 @@
 #string STR_CHIPSET_CUSTOM_CPU_CLOCK_PROMPT #language en-US "CPU Clock Rate 
(MHz)"
 #string STR_CHIPSET_CUSTOM_CPU_CLOCK_HELP   #language en-US "Adjust the CPU 
speed.\nMin value: 100 MHz\nMax value: 1600 MHz\n\nWarning: Overclocking can 
make the system unbootable!"

-#string STR_CHIPSET_SD_PROMPT#language en-US "uSD Routing"
-#string STR_CHIPSET_SD_HELP  #language en-US "Choose host controller 
to drive uSD slot"
-#string STR_CHIPSET_SD_SDHOST#language en-US "Broadcom SDHOST"
-#string STR_CHIPSET_SD_ARASAN#language en-US "Arasan SDHCI"
-
 /*
  * Advanced configuration.
  */
@@ -55,8 +50,13 @@
  * MMC/SD configuration.
  */

-#string STR_MMC_FORM_TITLE   #language en-US "SD/MMC Tweaks"
-#string STR_MMC_FORM_SUBTITLE#language en-US "Note: UEFI only, OS will 
override settings when booted."
+#string STR_MMC_FORM_TITLE   #language en-US "SD/MMC Configuration"
+#string STR_MMC_FORM_SUBTITLE#language en-US "Note: UEFI only, OS may 
override settings."
+
+#string STR_MMC_SD_PROMPT#language en-US "uSD Routing"
+#string STR_MMC_SD_HELP  #language en-US "Choose host controller to 
drive uSD slot"
+#string STR_MMC_SD_SDHOST#language en-US "Broadcom SDHOST"
+#string STR_MMC_SD_ARASAN#language en-US "Arasan SDHCI"

 #string STR_MMC_DISMULTI_PROMPT  #language en-US "Multi-Block Support"
 #string STR_MMC_DISMULTI_HELP#language en-US "Use CMD18/CMD25 for 
transfers when possible"
@@ -84,7 +84,7 @@
  * Display settings.
  */

-#string STR_DISPLAY_FORM_TITLE  #language en-US "Display"
+#string STR_DISPLAY_FORM_TITLE  #language en-US "Display Configuration"
 #string STR_DISPLAY_FORM_SUBTITLE   #language en-US "UEFI video driver 
settings"

 #string STR_DISPLAY_VMODES_640_PROMPT  #language en-US "Virtual 640x480"
@@ -109,7 +109,7 @@
 /*
  * Debugging settings go here.
  */
-#string STR_DEBUG_FORM_TITLE#language en-US "Debugging"
+#string STR_DEBUG_FORM_TITLE#language en-US "Debugging Configuration"
 #string STR_DEBUG_FORM_SUBTITLE #language en-US "For UEFI/OS Developers"

 #string STR_DEBUG_JTAG_PROMPT   #language en-US "JTAG Routing"
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index d16058da4926..9c2fd64a8e27 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -65,14 +65,6 @@ typedef struct {
   UINT32 Clock;
 } CHIPSET_CUSTOM_CPU_CLOCK_VARSTORE_DATA;

-typedef struct {
-  /*
-   * 0 - uSD slot routed to Broadcom SDHOST.
-   * 1 - uSD slot routed to Arasan SDHCI.
-   */
-  UINT32 Routing;
-} CHIPSET_SD_VARSTORE_DATA;
-
 typedef struct {
   /*
* Always set by ConfigDxe prior to HII init to reflect
@@ -93,6 +85,14 @@ typedef struct {
   UINT32 Enabled;
 } ADVANCED_DEVICE_TREE_VARSTORE_DATA;

+typedef struct {
+  /*
+   * 0 - uSD slot routed to Broadcom SDHOST.
+   * 1 - uSD slot routed to Arasan SDHCI.
+   */
+  UINT32 Routing;
+} MMC_SD_VARSTORE_DATA;
+
 typedef struct {
   /*
* 0 - Don't disable multi-block.
@@ -155,11 +155,6 @@ formset
   name  = CustomCpuClock,
   guid  = CONFIGDXE_FORM_SET_GUID;

-efivarstore CHIPSET_SD_VARSTORE_DATA,
-  

Re: [edk2-devel][PATCH v2 6/6] Platform/RPi/ConfigDxe: Improve RPi configuration form

[Andrei Warkentin via Groups.Io]

Nevermind, I missed all the current reviews and the code is already in.

A


From: devel@edk2.groups.io  on behalf of Andrei Warkentin 
via Groups.Io 
Sent: Tuesday, March 3, 2020 11:17 AM
To: Pete Batard; devel@edk2.groups.io
Cc: ard.biesheu...@linaro.org; l...@nuviainc.com; phi...@redhat.com
Subject: Re: [edk2-devel][PATCH v2 6/6] Platform/RPi/ConfigDxe: Improve RPi 
configuration form

Reviewed-by: Andrei Warkentin 


From: Pete Batard 
Sent: Tuesday, March 3, 2020 8:08 AM
To: devel@edk2.groups.io
Cc: ard.biesheu...@linaro.org; l...@nuviainc.com; phi...@redhat.com; Andrei 
Warkentin
Subject: [edk2-devel][PATCH v2 6/6] Platform/RPi/ConfigDxe: Improve RPi 
configuration form

Group all SD/MMC settings under the SD/MMC form.
Make CPU settings more prominent.
Harmonise form titles and text content.
Reorder forms in the order they are most likely to be queried.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni | 24 +-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 50 
++--
 2 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 2e79e322e558..77eda96d8136 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -14,11 +14,11 @@
 #string STR_FORM_SET_TITLE_HELP  #language en-US "Press  to configure 
system settings."

 /*
- * Chipset config.
+ * Chipset configuration.
  */

-#string STR_CHIPSET_FORM_TITLE  #language en-US "Chipset Configuration"
-#string STR_CHIPSET_FORM_SUBTITLE   #language en-US "Note: OS may override 
settings when booted."
+#string STR_CHIPSET_FORM_TITLE  #language en-US "CPU Configuration"
+#string STR_CHIPSET_FORM_SUBTITLE   #language en-US "Note: OS may override 
settings."

 #string STR_CHIPSET_CLOCK_CPU_PROMPT #language en-US "CPU Clock"
 #string STR_CHIPSET_CLOCK_CPU_HELP   #language en-US "CPU Speed"
@@ -30,11 +30,6 @@
 #string STR_CHIPSET_CUSTOM_CPU_CLOCK_PROMPT #language en-US "CPU Clock Rate 
(MHz)"
 #string STR_CHIPSET_CUSTOM_CPU_CLOCK_HELP   #language en-US "Adjust the CPU 
speed.\nMin value: 100 MHz\nMax value: 1600 MHz\n\nWarning: Overclocking can 
make the system unbootable!"

-#string STR_CHIPSET_SD_PROMPT#language en-US "uSD Routing"
-#string STR_CHIPSET_SD_HELP  #language en-US "Choose host controller 
to drive uSD slot"
-#string STR_CHIPSET_SD_SDHOST#language en-US "Broadcom SDHOST"
-#string STR_CHIPSET_SD_ARASAN#language en-US "Arasan SDHCI"
-
 /*
  * Advanced configuration.
  */
@@ -55,8 +50,13 @@
  * MMC/SD configuration.
  */

-#string STR_MMC_FORM_TITLE   #language en-US "SD/MMC Tweaks"
-#string STR_MMC_FORM_SUBTITLE#language en-US "Note: UEFI only, OS will 
override settings when booted."
+#string STR_MMC_FORM_TITLE   #language en-US "SD/MMC Configuration"
+#string STR_MMC_FORM_SUBTITLE#language en-US "Note: UEFI only, OS may 
override settings."
+
+#string STR_MMC_SD_PROMPT#language en-US "uSD Routing"
+#string STR_MMC_SD_HELP  #language en-US "Choose host controller to 
drive uSD slot"
+#string STR_MMC_SD_SDHOST#language en-US "Broadcom SDHOST"
+#string STR_MMC_SD_ARASAN#language en-US "Arasan SDHCI"

 #string STR_MMC_DISMULTI_PROMPT  #language en-US "Multi-Block Support"
 #string STR_MMC_DISMULTI_HELP#language en-US "Use CMD18/CMD25 for 
transfers when possible"
@@ -84,7 +84,7 @@
  * Display settings.
  */

-#string STR_DISPLAY_FORM_TITLE  #language en-US "Display"
+#string STR_DISPLAY_FORM_TITLE  #language en-US "Display Configuration"
 #string STR_DISPLAY_FORM_SUBTITLE   #language en-US "UEFI video driver 
settings"

 #string STR_DISPLAY_VMODES_640_PROMPT  #language en-US "Virtual 640x480"
@@ -109,7 +109,7 @@
 /*
  * Debugging settings go here.
  */
-#string STR_DEBUG_FORM_TITLE#language en-US "Debugging"
+#string STR_DEBUG_FORM_TITLE#language en-US "Debugging Configuration"
 #string STR_DEBUG_FORM_SUBTITLE #language en-US "For UEFI/OS Developers"

 #string STR_DEBUG_JTAG_PROMPT   #language en-US "JTAG Routing"
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index d16058da4926..9c2fd64a8e27 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -65,14 +65,6 @@ typedef struct {
   UINT32 Clock;
 } CHIPSET_CUSTOM_CPU_CLOCK_VARSTORE_DATA;

-typedef struct {
-  /*
-   * 0 - uSD slot routed to Broadcom SDHOST.
-   * 1 - uSD slot routed to Arasan SDHCI.
-   */
-  UINT32 Routing;
-} CHIPSET_SD_VARSTORE_DATA;
-
 typedef struct {
   /*
* Always set by ConfigDxe prior to HII init to reflect
@@ -93,6 +85,14 @@ typedef struct {
   UI

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

[Marvin Häuser]

Good day,

Unfortunately, this discussion has died again. This is fine by me, I'm 
also fine with the already proposed patch and mostly shared different 
approaches based on the vastly diverging feedback, but it works for us 
either way.

Can the patch please be reviewed and accepted for the next stable tag? 
Thanks!

Best regards,
Marvin

Am 20.02.2020 um 11:18 schrieb Marvin Häuser:
> Hey Andrew,
> 
> Thanks once again for your comments, mine are inline.
> 
> Best regards,
> Marvin
> 
> Am 20.02.2020 um 00:55 schrieb Andrew Fish:
>>
>>
>>> On Feb 17, 2020, at 12:26 AM, Marvin Häuser >> > wrote:
>>>
>>> Good day Andrew,
>>>
>>> First of all, thank you very much for putting this amount of thought
>>> into the situation. I definitely agree with the problem you see, but I
>>> could also live with Vitaly's proposal. However, I think you are
>>> overcomplicating the situation a little. So, we do agree the caller
>>> needs control of the behaviour, however your proposal needs "support"
>>> from both the caller (choose the handler) and the callee (call the
>>> handler) and is neither thread-safe nor event-safe as Vitaly already
>>> pointed out. Fixing these problems would only worsen the complexity
>>> situation in my opinion.
>>
>> Well EFI does not have Threads but it does have Events. I agree if an
> 
> Sorry, we were refering to the UEFI Multi-Processor services, so threads
> in a physical sense. I think very similar concerns apply regarding these
> services as with software multithreading in this context, please correct
> me if I'm wrong.
> 
>> Event handler changes the constraint handler it would need to restore it
>> so my proposal is missing an API.
>>
>> CONSTRAINT_HANDLER *
>> GetConstraintHandler (
>>     VOID
>>     )
>> {
>>     return gActiveConstraintHandler;
>> }
>>
>> You an always use the standard EFI
>>
>> It is important to remember that all the EFI images
>> (drivers/applications) are statically linked and they carry a unique
>> instance of the Debug (or new Constraint) lib. So in your driver or App
>> is very self contained. Also a lot of the events are phase related
>> callbacks, and since there are no threads your drivers main thread is
>> only really running when your driver, or app, dispatches. A lot of the
>> callbacks are via protocols your driver publishes, but they have strict
>> TPL rules so you can prevent reentrancy in general. So there is a lot
>> more determinism in EFI vs. generic threaded coding.
> 
> This is true, but yet all edge-cases should be covered (event
> "interruption", actual (processor) interrupts, Multi-Processor
> execution), so developers do not run into unexpected (seemingly)
> undeterministic behaviour. However, I agree it is easier to ensure for
> something like UEFI than for a full-fledged OS of course.
> 
>>
>>>
>>> Diverging from both of your concepts entirely and keeping it very
>>> simple, what keeps us from simply ASSERTing based on return value? We
>>> could introduce a CONSTRAINT_ASSERT or similar, but it would be
>>> completely different from Vitaly's proposal. It would be a caller macro
>>> to ASSERT based on a pre-defined list of return statuses.
>>> To achieve this, we would order all statuses by types (classes). At the
>>> moment, I can only think of two: "environmental" and "constraint". For
>>> example, "Out Of Resources" would be environmental and "Invalid
>>> Parameter" would be constraint. We could define environment statuses
>>> explicitly (as it is less likely new environment statuses are
>>> introduced) and define constraint statuses as "not environmental" (to
>>> silently support new constraint statuses, however of course it is a
>>> little error-prone with forwards-compatibility). As a bonus, it forces
>>> developers to use truly appropiate error codes and correctly propagate
>>> them from callees for this to work. :)
>>> This solution would be backwards-compatible in a compilation sense as it
>>> can simply be a new macro, however for its possible complexity (switch
>>> cases) I might actually prefer a function. But it would not be
>>> backwards-compatible with the current functionality, which none of the
>>> "caller-based" concepts can be anyway (the caller needs explicit code).
>>>
>>
>> It is an interesting idea to add granularity, but at the end of the
>> knowledge of the correct behavior of the lower level library code really
>> lives in code that calls this. I will admit I can see some value to
>> making RETURN_INVALID_PARAMETER different than RETURN_BUFFER_TOO_SMALL.
> 
> So far, I prefer this idea as the only requirement is that function
> contracts are well-designed (i.e. reflect environmental vs constraint
> errors by using sensical return values).
> 
>>
>> I kind of went down the C11 path (thanks for mentioning the event issue)
>> but there are other ways to empower the caller.
> 
> It's definitely always a good idea to stick to standards and
> conventions. It appears my proposal is not conventio

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

[Andrew Fish via Groups.Io]

Marvin,

If no one else objects to your proposal I don't want to block forward progress. 
My main intent was to have a conversation about this topic. 


> On Feb 20, 2020, at 2:18 AM, Marvin Häuser  wrote:
> 
> Hey Andrew,
> 
> Thanks once again for your comments, mine are inline.
> 
> Best regards,
> Marvin
> 
> Am 20.02.2020 um 00:55 schrieb Andrew Fish:
>> 
>> 
>>> On Feb 17, 2020, at 12:26 AM, Marvin Häuser >> > wrote:
>>> 
>>> Good day Andrew,
>>> 
>>> First of all, thank you very much for putting this amount of thought
>>> into the situation. I definitely agree with the problem you see, but I
>>> could also live with Vitaly's proposal. However, I think you are
>>> overcomplicating the situation a little. So, we do agree the caller
>>> needs control of the behaviour, however your proposal needs "support"
>>> from both the caller (choose the handler) and the callee (call the
>>> handler) and is neither thread-safe nor event-safe as Vitaly already
>>> pointed out. Fixing these problems would only worsen the complexity
>>> situation in my opinion.
>> 
>> Well EFI does not have Threads but it does have Events. I agree if an 
> 
> Sorry, we were refering to the UEFI Multi-Processor services, so threads 
> in a physical sense. I think very similar concerns apply regarding these 
> services as with software multithreading in this context, please correct 
> me if I'm wrong.

It is not legal to do anything EFI on the APs. The locks in the DXE Core are 
TPL based so that is a software construct that only exists on the BSP. 

Technically speaking from a LibraryClass definition you should not run any libs 
that have ASSERT or DEBUG macros on the AP given the DebugLib Library Class is 
not MP safe. In reality it is possible to have an MP safe version of the 
DebugLib, and it is likely people are just getting away with MdePkg libs since 
it is not an issue unless they ASSERT or DEBUG print. 

I'd also point out that most code does not do work on the APs. On a typical  
x86 firmware it is Microcode, SMM, and the driver producing the MP Services 
than run code on the APs. While most other code does not. 

Note: EFI runs on the BSP, the other CPUs in the systems are called APs. 

Thanks,

Andrew Fish

> 
>> Event handler changes the constraint handler it would need to restore it 
>> so my proposal is missing an API.
>> 
>> CONSTRAINT_HANDLER *
>> GetConstraintHandler (
>>   VOID
>>   )
>> {
>>   return gActiveConstraintHandler;
>> }
>> 
>> You an always use the standard EFI
>> 
>> It is important to remember that all the EFI images 
>> (drivers/applications) are statically linked and they carry a unique 
>> instance of the Debug (or new Constraint) lib. So in your driver or App 
>> is very self contained. Also a lot of the events are phase related 
>> callbacks, and since there are no threads your drivers main thread is 
>> only really running when your driver, or app, dispatches. A lot of the 
>> callbacks are via protocols your driver publishes, but they have strict 
>> TPL rules so you can prevent reentrancy in general. So there is a lot 
>> more determinism in EFI vs. generic threaded coding.
> 
> This is true, but yet all edge-cases should be covered (event 
> "interruption", actual (processor) interrupts, Multi-Processor 
> execution), so developers do not run into unexpected (seemingly) 
> undeterministic behaviour. However, I agree it is easier to ensure for 
> something like UEFI than for a full-fledged OS of course.
> 
>> 
>>> 
>>> Diverging from both of your concepts entirely and keeping it very
>>> simple, what keeps us from simply ASSERTing based on return value? We
>>> could introduce a CONSTRAINT_ASSERT or similar, but it would be
>>> completely different from Vitaly's proposal. It would be a caller macro
>>> to ASSERT based on a pre-defined list of return statuses.
>>> To achieve this, we would order all statuses by types (classes). At the
>>> moment, I can only think of two: "environmental" and "constraint". For
>>> example, "Out Of Resources" would be environmental and "Invalid
>>> Parameter" would be constraint. We could define environment statuses
>>> explicitly (as it is less likely new environment statuses are
>>> introduced) and define constraint statuses as "not environmental" (to
>>> silently support new constraint statuses, however of course it is a
>>> little error-prone with forwards-compatibility). As a bonus, it forces
>>> developers to use truly appropiate error codes and correctly propagate
>>> them from callees for this to work. :)
>>> This solution would be backwards-compatible in a compilation sense as it
>>> can simply be a new macro, however for its possible complexity (switch
>>> cases) I might actually prefer a function. But it would not be
>>> backwards-compatible with the current functionality, which none of the
>>> "caller-based" concepts can be anyway (the caller needs explicit code).
>>> 
>> 
>> It is an interesting idea to add granularity, but at

Re: [edk2-devel] [PATCH v4 6/7] OvmfPkg IA32: add support for loading X64 images

[Laszlo Ersek]

On 03/03/20 15:01, Ard Biesheuvel wrote:
> This is the UEFI counterpart to my Linux series which generalizes
> mixed mode support into a feature that requires very little internal
> knowledge about the architecture specifics of booting Linux on the
> part of the bootloader or firmware.
> 
> Instead, we add a .compat PE/COFF header containing an array of
> PE_COMPAT nodes containing  tuples that
> describe alternate entrypoints into the image for different native
> machine types, e.g., IA-32 in a 64-bit image so it can be booted
> from IA-32 firmware.
> 
> This patch implements the PE/COFF emulator protocol to take this new
> section into account, so that such images can simply be loaded via
> LoadImage/StartImage, e.g., straight from the shell.
> 
> This feature is based on the EDK2 specific PE/COFF emulator protocol
> that was introduced in commit 57df17fe26cd ("MdeModulePkg/DxeCore:
> invoke the emulator protocol for foreign images", 2019-04-14).
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
> Signed-off-by: Ard Biesheuvel 
> Acked-by: Laszlo Ersek 
> ---
>  OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c   | 143 
> 
>  OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.inf |  37 +
>  OvmfPkg/OvmfPkgIa32.dsc   |   5 +
>  OvmfPkg/OvmfPkgIa32.fdf   |   4 +
>  4 files changed, 189 insertions(+)
> 
> diff --git a/OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c 
> b/OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c
> new file mode 100644
> index ..ae47917f1589
> --- /dev/null
> +++ b/OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c
> @@ -0,0 +1,143 @@
> +/** @file
> + *  PE/COFF emulator protocol implementation to start Linux kernel
> + *  images from non-native firmware
> + *
> + *  Copyright (c) 2020, ARM Ltd. All rights reserved.
> + *
> + *  SPDX-License-Identifier: BSD-2-Clause-Patent
> + *
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#pragma pack (1)
> +typedef struct {
> +  UINT8   Type;
> +  UINT8   Size;
> +  UINT16  MachineType;
> +  UINT32  EntryPoint;
> +} PE_COMPAT_TYPE1;
> +#pragma pack ()
> +
> +STATIC
> +BOOLEAN
> +EFIAPI
> +IsImageSupported (
> +  IN  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
> +  IN  UINT16  ImageType,
> +  IN  EFI_DEVICE_PATH_PROTOCOL*DevicePath   OPTIONAL
> +  )
> +{
> +  return ImageType == EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION;
> +}
> +
> +STATIC
> +EFI_IMAGE_ENTRY_POINT
> +EFIAPI
> +GetCompatEntryPoint (
> +  IN  EFI_PHYSICAL_ADDRESS  ImageBase
> +  )
> +{
> +  EFI_IMAGE_DOS_HEADER  *DosHdr;
> +  UINTN PeCoffHeaderOffset;
> +  EFI_IMAGE_NT_HEADERS32*Pe32;
> +  EFI_IMAGE_SECTION_HEADER  *Section;
> +  UINTN NumberOfSections;
> +  PE_COMPAT_TYPE1   *PeCompat;
> +  VOID  *PeCompatEnd;
> +
> +  DosHdr = (EFI_IMAGE_DOS_HEADER *)(UINTN)ImageBase;
> +  if (DosHdr->e_magic != EFI_IMAGE_DOS_SIGNATURE) {
> +return NULL;
> +  }
> +
> +  PeCoffHeaderOffset = DosHdr->e_lfanew;
> +  Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN)ImageBase + PeCoffHeaderOffset);
> +
> +  Section = (EFI_IMAGE_SECTION_HEADER *)((UINTN)&Pe32->OptionalHeader +
> + 
> Pe32->FileHeader.SizeOfOptionalHeader);
> +  NumberOfSections = (UINTN)Pe32->FileHeader.NumberOfSections;
> +
> +  while (NumberOfSections--) {
> +if (!CompareMem (Section->Name, ".compat", sizeof (Section->Name))) {
> +  //
> +  // Dereference the section contents to find the mixed mode entry point
> +  //
> +  PeCompat = (PE_COMPAT_TYPE1 *)((UINTN)ImageBase + 
> Section->VirtualAddress);
> +  PeCompatEnd = (UINT8 *)PeCompat + Section->Misc.VirtualSize;
> +
> +  while (PeCompat->Type != 0 && (VOID *)PeCompat < PeCompatEnd) {
> +if (PeCompat->Type == 1 &&
> +PeCompat->Size >= sizeof (PE_COMPAT_TYPE1) &&
> +EFI_IMAGE_MACHINE_TYPE_SUPPORTED (PeCompat->MachineType)) {
> +
> +  return (EFI_IMAGE_ENTRY_POINT)((UINTN)ImageBase + 
> PeCompat->EntryPoint);
> +}
> +PeCompat = (PE_COMPAT_TYPE1 *)((UINTN)PeCompat + PeCompat->Size);
> +ASSERT ((VOID *)PeCompat < PeCompatEnd);

The new pointer comparisons make me really uncomfortable. They look
doubly undefined:

(a) comparing (VOID*) against a pointer to a complete type. The C99
standard says:

--
6.5.8 Relational operators

Constraints

2 One of the following shall hold:
  - both operands have real type;
  - both operands are pointers to qualified or unqualified versions of
compatible object types; or
  - both operands are pointers to qualified or unqualified versions of
compatible incomplete types.
--

"void" is an incomplete type that cannot be completed (it is ne

Re: [edk2-devel] [PATCH v4 7/7] OvmfPkg/LinuxInitrdDynamicShellCommand: bail if initrd already exists

[Laszlo Ersek]

On 03/03/20 15:01, Ard Biesheuvel wrote:
> Before taking any actions, check if an instance of the LoadFile2 exists
> already on the Linux initrd media GUID device path, and whether it was
> provided by this command. If so, abort, since no duplicate instances of
> the device path should exist.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c   | 
> 31 
>  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni |  
> 3 ++
>  2 files changed, 34 insertions(+)
> 
> diff --git 
> a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c 
> b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
> index 47ed26b50d3a..ed8fbaa77069 100644
> --- a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
> +++ b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
> @@ -53,6 +53,33 @@ STATIC CONST SINGLE_NODE_VENDOR_MEDIA_DEVPATH 
> mInitrdDevicePath = {
>}
>  };
>  
> +STATIC
> +BOOLEAN
> +IsOtherInitrdDevicePathAlreadyInstalled (
> +  VOID
> +  )
> +{
> +  EFI_STATUS  Status;
> +  EFI_DEVICE_PATH_PROTOCOL*DevicePath;
> +  EFI_HANDLE  Handle;
> +
> +  DevicePath = (EFI_DEVICE_PATH_PROTOCOL *)&mInitrdDevicePath;
> +  Status = gBS->LocateDevicePath (&gEfiLoadFile2ProtocolGuid, &DevicePath,
> +  &Handle);
> +  if (EFI_ERROR (Status)) {
> +return FALSE;
> +  }
> +
> +  //
> +  // Check whether the existing instance is one that we installed during
> +  // a previous invocation.
> +  //
> +  if (Handle == mInitrdLoadFile2Handle) {
> +return FALSE;
> +  }
> +  return TRUE;
> +}

Looks good, the function will return TRUE when mInitrdLoadFile2Handle is
NULL.

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo


> +
>  STATIC
>  EFI_STATUS
>  EFIAPI
> @@ -217,6 +244,10 @@ RunInitrd (
>  } else {
>ASSERT(FALSE);
>  }
> +  } else if (IsOtherInitrdDevicePathAlreadyInstalled ()) {
> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ALREADY_INSTALLED),
> +  mLinuxInitrdShellCommandHiiHandle, L"initrd");
> +ShellStatus = SHELL_UNSUPPORTED;
>} else {
>  if (ShellCommandLineGetCount (Package) > 2) {
>ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_TOO_MANY),
> diff --git 
> a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni 
> b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
> index a88fa6e3641b..4b6b1285fffd 100644
> --- 
> a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
> +++ 
> b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
> @@ -18,6 +18,7 @@
>  #langdef   en-US "english"
>  
>  #string STR_GEN_PROBLEM   #language en-US "%H%s%N: Unknown flag - 
> '%H%s%N'\r\n"
> +#string STR_GEN_ALREADY_INSTALLED #language en-US "%H%s%N: Linux initrd 
> already provided by platform\r\n"
>  #string STR_GEN_TOO_MANY  #language en-US "%H%s%N: Too many 
> arguments.\r\n"
>  #string STR_GEN_TOO_FEW   #language en-US "%H%s%N: Too few 
> arguments.\r\n"
>  #string STR_GEN_FIND_FAIL #language en-US "%H%s%N: File not found - 
> '%H%s%N'\r\n"
> @@ -47,3 +48,5 @@
>  " Consumers of the LoadFile2 protocol on the 
> LINUX_EFI_INITRD_MEDIA_GUID\r\n"
>  " device path that are started via means other than the shell will be 
> able\r\n"
>  " to locate the protocol and invoke it.\r\n"
> +"  3. Exposing an initrd using this command is only supported if no initrd 
> is\r\n"
> +" already being exposed by another driver on the platform.\r\n"
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55344): https://edk2.groups.io/g/devel/message/55344
Mute This Topic: https://groups.io/mt/71700589/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 7/7] OvmfPkg/LinuxInitrdDynamicShellCommand: bail if initrd already exists

[Laszlo Ersek]

On 03/03/20 22:03, Laszlo Ersek wrote:
> On 03/03/20 15:01, Ard Biesheuvel wrote:
>> Before taking any actions, check if an instance of the LoadFile2 exists
>> already on the Linux initrd media GUID device path, and whether it was
>> provided by this command. If so, abort, since no duplicate instances of
>> the device path should exist.
>>
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c   | 
>> 31 
>>  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni | 
>>  3 ++
>>  2 files changed, 34 insertions(+)
>>
>> diff --git 
>> a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c 
>> b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
>> index 47ed26b50d3a..ed8fbaa77069 100644
>> --- a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
>> +++ b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
>> @@ -53,6 +53,33 @@ STATIC CONST SINGLE_NODE_VENDOR_MEDIA_DEVPATH 
>> mInitrdDevicePath = {
>>}
>>  };
>>  
>> +STATIC
>> +BOOLEAN
>> +IsOtherInitrdDevicePathAlreadyInstalled (
>> +  VOID
>> +  )
>> +{
>> +  EFI_STATUS  Status;
>> +  EFI_DEVICE_PATH_PROTOCOL*DevicePath;
>> +  EFI_HANDLE  Handle;
>> +
>> +  DevicePath = (EFI_DEVICE_PATH_PROTOCOL *)&mInitrdDevicePath;
>> +  Status = gBS->LocateDevicePath (&gEfiLoadFile2ProtocolGuid, &DevicePath,
>> +  &Handle);
>> +  if (EFI_ERROR (Status)) {
>> +return FALSE;
>> +  }
>> +
>> +  //
>> +  // Check whether the existing instance is one that we installed during
>> +  // a previous invocation.
>> +  //
>> +  if (Handle == mInitrdLoadFile2Handle) {
>> +return FALSE;
>> +  }
>> +  return TRUE;
>> +}
> 
> Looks good, the function will return TRUE when mInitrdLoadFile2Handle is
> NULL.

To clarify, what I mean is that the controlling expression

  (Handle == mInitrdLoadFile2Handle)

assuming it is reached, will evaluate to 0, if mInitrdLoadFile2Handle is
NULL. That's because Handle cannot be NULL at that point. Hence the
function will return TRUE.

Thanks
Laszlo

> Reviewed-by: Laszlo Ersek 
> 
> Thanks
> Laszlo
> 
> 
>> +
>>  STATIC
>>  EFI_STATUS
>>  EFIAPI
>> @@ -217,6 +244,10 @@ RunInitrd (
>>  } else {
>>ASSERT(FALSE);
>>  }
>> +  } else if (IsOtherInitrdDevicePathAlreadyInstalled ()) {
>> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ALREADY_INSTALLED),
>> +  mLinuxInitrdShellCommandHiiHandle, L"initrd");
>> +ShellStatus = SHELL_UNSUPPORTED;
>>} else {
>>  if (ShellCommandLineGetCount (Package) > 2) {
>>ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_TOO_MANY),
>> diff --git 
>> a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni 
>> b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
>> index a88fa6e3641b..4b6b1285fffd 100644
>> --- 
>> a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
>> +++ 
>> b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
>> @@ -18,6 +18,7 @@
>>  #langdef   en-US "english"
>>  
>>  #string STR_GEN_PROBLEM   #language en-US "%H%s%N: Unknown flag - 
>> '%H%s%N'\r\n"
>> +#string STR_GEN_ALREADY_INSTALLED #language en-US "%H%s%N: Linux initrd 
>> already provided by platform\r\n"
>>  #string STR_GEN_TOO_MANY  #language en-US "%H%s%N: Too many 
>> arguments.\r\n"
>>  #string STR_GEN_TOO_FEW   #language en-US "%H%s%N: Too few 
>> arguments.\r\n"
>>  #string STR_GEN_FIND_FAIL #language en-US "%H%s%N: File not found - 
>> '%H%s%N'\r\n"
>> @@ -47,3 +48,5 @@
>>  " Consumers of the LoadFile2 protocol on the 
>> LINUX_EFI_INITRD_MEDIA_GUID\r\n"
>>  " device path that are started via means other than the shell will be 
>> able\r\n"
>>  " to locate the protocol and invoke it.\r\n"
>> +"  3. Exposing an initrd using this command is only supported if no initrd 
>> is\r\n"
>> +" already being exposed by another driver on the platform.\r\n"
>>
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55345): https://edk2.groups.io/g/devel/message/55345
Mute This Topic: https://groups.io/mt/71700589/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Disabling safe string constraint assertions

[Vitaly Cheptsov]

Hello,

I am creating a new thread for this issue, as for some reason half of my 
messages do not display in the web-interface and some of e-mail clients in the 
previous one. It seems that somebody sent broken HTML code to groups.io 
, and it did not like to be quoted. It will be quite nice if 
all the messages sent are plain-text to avoid such issues in the future.

Back to the issue, we want to make constraint assertions 
(SAFE_STRING_CONSTRAINT_CHECK) in SafeString.c be optionally disabled in DEBUG 
builds, as they break our ability to use some of BaseLib interfaces to verify 
untrusted user data in UEFI Applications. The background of this problem is 
covered in a bugzilla[1], and was also extensively discussed in the last 
proposed patch discussion thread[2]. We want the solution to the problem to 
land in the next stable tag: edk2-stable202005, and can submit the patch.

Currently there is no clear decision on what approach to take, as there are 
three different proposals to implement:

1) Andrew Fish’s approach with C11-like constraint handler[3].
2) Marvin Häuser’s approach with return codes and constraint assertions being 
moved to the caller side[4].
3) My approach suggesting DebugLib interface simplification, permitting us to 
resolve the problem and keep backwards compatibility[5].

My personal opinion is that:

— Marvin’s way is very interesting, but it would require implementing code on 
the caller side basically for every call, and this would requires extra 
programming effort. It may also be uneasy to teach people how to do this right, 
and this does not strictly provide a good solution for situations, where 
nesting is more than 2 (i.e. when user code calls library code, which itself 
calls library code). Because of these downsides I am afraid it is impractical 
to adopt it in EDK II.
— Andrew’s way is reasonable from the C standard point of view, but it does not 
work quite right with reentrancy and I am not positive we need the dynamic 
handling, especially because of DEBUG/RELEASE build confusion. I explained this 
in my previous e-mail, which I attached to the end of this message as quote, 
since groups.io  ate the previous send. Other than that, I 
would say that I can implement this approach if there is no other option.
— My own approach makes sense, as it reduces the amount of code in every 
DebugLib and actually simplifies the development in the future. I believe 
currently this is the most reasonable route we can take, and suggest other 
parties to consider it.

Since the three of us each have their own suggestions, I ask Mike and others to 
rejoin our discussions and give their opinions quickly, so that we can choose, 
perhaps vote, and proceed with the implementation. Thanks for your dedication.

Best wishes,
Vitaly

[1] https://bugzilla.tianocore.org/show_bug.cgi?id=2054 

[2] https://edk2.groups.io/g/devel/topic/69401948 

[3] https://edk2.groups.io/g/devel/message/54520 

[4] https://edk2.groups.io/g/devel/message/54544 

[5] https://edk2.groups.io/g/devel/message/54499 



> Andrew,
> 
> I am not sure you received my message with the explanations[1], where I 
> believe I covered the nuances, but it is nice to see you on the tune.
> 
> Making EDK II replicate more of the functionality from Bounds Checking Annex 
> from C11 is an interesting idea. The historical part of our SafeStringLib is 
> that it indeed tried to follow Microsoft's initial design (later contributed 
> as a C standard Annex K) but completely ignored the ability to configure the 
> handling logic. This is the problem we actually try to resolve here.
> 
> The reality behind this annex is, however, that very few implementations 
> agreed to adopt it, including C standard library in macOS. The design of its 
> functions permits some level of flexibility, but I think for most of their 
> uses it is not strictly necessary or is not easily achievable. For example, 
> one of the largest problems of this annex is that it entirely ignores threads 
> or reentrancy. In EDK II we do not (yet) have threads in their true sense, 
> but we do have events, which can interrupt code execution.
> 
> The code you presented is not strictly safe, as without TPL adjustment it may 
> affect the behaviour of some random event handler. Thus the most likely use 
> of the constraint handler configuration will be not changing it before the 
> call to a function, but rather configuring close to the entry point of an 
> application or a driver. For this exact reason it is questionable whether the 
> need to have it configurable in runtime is actually needed. Or rather it is 
> questionable whether anybody will actually use it and if he does, whether he 
> will able to

Re: [edk2-devel] [PATCH v4 7/7] OvmfPkg/LinuxInitrdDynamicShellCommand: bail if initrd already exists

[Ard Biesheuvel]

On Tue, 3 Mar 2020 at 22:08, Laszlo Ersek  wrote:
>
> On 03/03/20 22:03, Laszlo Ersek wrote:
> > On 03/03/20 15:01, Ard Biesheuvel wrote:
> >> Before taking any actions, check if an instance of the LoadFile2 exists
> >> already on the Linux initrd media GUID device path, and whether it was
> >> provided by this command. If so, abort, since no duplicate instances of
> >> the device path should exist.
> >>
> >> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c   
> >> | 31 
> >>  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni 
> >> |  3 ++
> >>  2 files changed, 34 insertions(+)
> >>
> >> diff --git 
> >> a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c 
> >> b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
> >> index 47ed26b50d3a..ed8fbaa77069 100644
> >> --- 
> >> a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
> >> +++ 
> >> b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
> >> @@ -53,6 +53,33 @@ STATIC CONST SINGLE_NODE_VENDOR_MEDIA_DEVPATH 
> >> mInitrdDevicePath = {
> >>}
> >>  };
> >>
> >> +STATIC
> >> +BOOLEAN
> >> +IsOtherInitrdDevicePathAlreadyInstalled (
> >> +  VOID
> >> +  )
> >> +{
> >> +  EFI_STATUS  Status;
> >> +  EFI_DEVICE_PATH_PROTOCOL*DevicePath;
> >> +  EFI_HANDLE  Handle;
> >> +
> >> +  DevicePath = (EFI_DEVICE_PATH_PROTOCOL *)&mInitrdDevicePath;
> >> +  Status = gBS->LocateDevicePath (&gEfiLoadFile2ProtocolGuid, &DevicePath,
> >> +  &Handle);
> >> +  if (EFI_ERROR (Status)) {
> >> +return FALSE;
> >> +  }
> >> +
> >> +  //
> >> +  // Check whether the existing instance is one that we installed during
> >> +  // a previous invocation.
> >> +  //
> >> +  if (Handle == mInitrdLoadFile2Handle) {
> >> +return FALSE;
> >> +  }
> >> +  return TRUE;
> >> +}
> >
> > Looks good, the function will return TRUE when mInitrdLoadFile2Handle is
> > NULL.
>
> To clarify, what I mean is that the controlling expression
>
>   (Handle == mInitrdLoadFile2Handle)
>
> assuming it is reached, will evaluate to 0, if mInitrdLoadFile2Handle is
> NULL. That's because Handle cannot be NULL at that point. Hence the
> function will return TRUE.
>

Indeed

> > Reviewed-by: Laszlo Ersek 
> >

Thanks!

I will push this series (asl well as the TPM one for ArmVirtPkg)
tomorrow, once the stable tag is assigned.


> >
> >
> >> +
> >>  STATIC
> >>  EFI_STATUS
> >>  EFIAPI
> >> @@ -217,6 +244,10 @@ RunInitrd (
> >>  } else {
> >>ASSERT(FALSE);
> >>  }
> >> +  } else if (IsOtherInitrdDevicePathAlreadyInstalled ()) {
> >> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
> >> (STR_GEN_ALREADY_INSTALLED),
> >> +  mLinuxInitrdShellCommandHiiHandle, L"initrd");
> >> +ShellStatus = SHELL_UNSUPPORTED;
> >>} else {
> >>  if (ShellCommandLineGetCount (Package) > 2) {
> >>ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_TOO_MANY),
> >> diff --git 
> >> a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
> >>  
> >> b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
> >> index a88fa6e3641b..4b6b1285fffd 100644
> >> --- 
> >> a/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
> >> +++ 
> >> b/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.uni
> >> @@ -18,6 +18,7 @@
> >>  #langdef   en-US "english"
> >>
> >>  #string STR_GEN_PROBLEM   #language en-US "%H%s%N: Unknown flag - 
> >> '%H%s%N'\r\n"
> >> +#string STR_GEN_ALREADY_INSTALLED #language en-US "%H%s%N: Linux initrd 
> >> already provided by platform\r\n"
> >>  #string STR_GEN_TOO_MANY  #language en-US "%H%s%N: Too many 
> >> arguments.\r\n"
> >>  #string STR_GEN_TOO_FEW   #language en-US "%H%s%N: Too few 
> >> arguments.\r\n"
> >>  #string STR_GEN_FIND_FAIL #language en-US "%H%s%N: File not found 
> >> - '%H%s%N'\r\n"
> >> @@ -47,3 +48,5 @@
> >>  " Consumers of the LoadFile2 protocol on the 
> >> LINUX_EFI_INITRD_MEDIA_GUID\r\n"
> >>  " device path that are started via means other than the shell will be 
> >> able\r\n"
> >>  " to locate the protocol and invoke it.\r\n"
> >> +"  3. Exposing an initrd using this command is only supported if no 
> >> initrd is\r\n"
> >> +" already being exposed by another driver on the platform.\r\n"
> >>
> >
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55347): https://edk2.groups.io/g/devel/message/55347
Mute This Topic: https://groups.io/mt/71700589/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 6/7] OvmfPkg IA32: add support for loading X64 images

[Ard Biesheuvel]

On Tue, 3 Mar 2020 at 21:54, Laszlo Ersek  wrote:
>
> On 03/03/20 15:01, Ard Biesheuvel wrote:
> > This is the UEFI counterpart to my Linux series which generalizes
> > mixed mode support into a feature that requires very little internal
> > knowledge about the architecture specifics of booting Linux on the
> > part of the bootloader or firmware.
> >
> > Instead, we add a .compat PE/COFF header containing an array of
> > PE_COMPAT nodes containing  tuples that
> > describe alternate entrypoints into the image for different native
> > machine types, e.g., IA-32 in a 64-bit image so it can be booted
> > from IA-32 firmware.
> >
> > This patch implements the PE/COFF emulator protocol to take this new
> > section into account, so that such images can simply be loaded via
> > LoadImage/StartImage, e.g., straight from the shell.
> >
> > This feature is based on the EDK2 specific PE/COFF emulator protocol
> > that was introduced in commit 57df17fe26cd ("MdeModulePkg/DxeCore:
> > invoke the emulator protocol for foreign images", 2019-04-14).
> >
> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
> > Signed-off-by: Ard Biesheuvel 
> > Acked-by: Laszlo Ersek 
> > ---
> >  OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c   | 143 
> > 
> >  OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.inf |  37 +
> >  OvmfPkg/OvmfPkgIa32.dsc   |   5 +
> >  OvmfPkg/OvmfPkgIa32.fdf   |   4 +
> >  4 files changed, 189 insertions(+)
> >
> > diff --git a/OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c 
> > b/OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c
> > new file mode 100644
> > index ..ae47917f1589
> > --- /dev/null
> > +++ b/OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.c
> > @@ -0,0 +1,143 @@
> > +/** @file
> > + *  PE/COFF emulator protocol implementation to start Linux kernel
> > + *  images from non-native firmware
> > + *
> > + *  Copyright (c) 2020, ARM Ltd. All rights reserved.
> > + *
> > + *  SPDX-License-Identifier: BSD-2-Clause-Patent
> > + *
> > + */
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#pragma pack (1)
> > +typedef struct {
> > +  UINT8   Type;
> > +  UINT8   Size;
> > +  UINT16  MachineType;
> > +  UINT32  EntryPoint;
> > +} PE_COMPAT_TYPE1;
> > +#pragma pack ()
> > +
> > +STATIC
> > +BOOLEAN
> > +EFIAPI
> > +IsImageSupported (
> > +  IN  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
> > +  IN  UINT16  ImageType,
> > +  IN  EFI_DEVICE_PATH_PROTOCOL*DevicePath   OPTIONAL
> > +  )
> > +{
> > +  return ImageType == EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION;
> > +}
> > +
> > +STATIC
> > +EFI_IMAGE_ENTRY_POINT
> > +EFIAPI
> > +GetCompatEntryPoint (
> > +  IN  EFI_PHYSICAL_ADDRESS  ImageBase
> > +  )
> > +{
> > +  EFI_IMAGE_DOS_HEADER  *DosHdr;
> > +  UINTN PeCoffHeaderOffset;
> > +  EFI_IMAGE_NT_HEADERS32*Pe32;
> > +  EFI_IMAGE_SECTION_HEADER  *Section;
> > +  UINTN NumberOfSections;
> > +  PE_COMPAT_TYPE1   *PeCompat;
> > +  VOID  *PeCompatEnd;
> > +
> > +  DosHdr = (EFI_IMAGE_DOS_HEADER *)(UINTN)ImageBase;
> > +  if (DosHdr->e_magic != EFI_IMAGE_DOS_SIGNATURE) {
> > +return NULL;
> > +  }
> > +
> > +  PeCoffHeaderOffset = DosHdr->e_lfanew;
> > +  Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN)ImageBase + PeCoffHeaderOffset);
> > +
> > +  Section = (EFI_IMAGE_SECTION_HEADER *)((UINTN)&Pe32->OptionalHeader +
> > + 
> > Pe32->FileHeader.SizeOfOptionalHeader);
> > +  NumberOfSections = (UINTN)Pe32->FileHeader.NumberOfSections;
> > +
> > +  while (NumberOfSections--) {
> > +if (!CompareMem (Section->Name, ".compat", sizeof (Section->Name))) {
> > +  //
> > +  // Dereference the section contents to find the mixed mode entry 
> > point
> > +  //
> > +  PeCompat = (PE_COMPAT_TYPE1 *)((UINTN)ImageBase + 
> > Section->VirtualAddress);
> > +  PeCompatEnd = (UINT8 *)PeCompat + Section->Misc.VirtualSize;
> > +
> > +  while (PeCompat->Type != 0 && (VOID *)PeCompat < PeCompatEnd) {
> > +if (PeCompat->Type == 1 &&
> > +PeCompat->Size >= sizeof (PE_COMPAT_TYPE1) &&
> > +EFI_IMAGE_MACHINE_TYPE_SUPPORTED (PeCompat->MachineType)) {
> > +
> > +  return (EFI_IMAGE_ENTRY_POINT)((UINTN)ImageBase + 
> > PeCompat->EntryPoint);
> > +}
> > +PeCompat = (PE_COMPAT_TYPE1 *)((UINTN)PeCompat + PeCompat->Size);
> > +ASSERT ((VOID *)PeCompat < PeCompatEnd);
>
> The new pointer comparisons make me really uncomfortable. They look
> doubly undefined:
>
> (a) comparing (VOID*) against a pointer to a complete type. The C99
> standard says:
>
> --
> 6.5.8 Relational operators
>
> Constraints
>
> 2 One of the following s

Re: [edk2-devel] Disabling safe string constraint assertions

[Andrew Fish via Groups.Io]

Vitaly,

I was planing on bringing it up at the Stewards meeting that was scheduled for 
today, but it got rescheduled to next week. So if we don't get traction on the 
mailing list I'll bring it up in the meeting. 

> On Mar 3, 2020, at 1:12 PM, Vitaly Cheptsov  wrote:
> 
> Hello,
> 
> I am creating a new thread for this issue, as for some reason half of my 
> messages do not display in the web-interface and some of e-mail clients in 
> the previous one. It seems that somebody sent broken HTML code to groups.io 
> , and it did not like to be quoted. It will be quite nice 
> if all the messages sent are plain-text to avoid such issues in the future.
> 
> Back to the issue, we want to make constraint assertions 
> (SAFE_STRING_CONSTRAINT_CHECK) in SafeString.c be optionally disabled in 
> DEBUG builds, as they break our ability to use some of BaseLib interfaces to 
> verify untrusted user data in UEFI Applications. The background of this 
> problem is covered in a bugzilla[1], and was also extensively discussed in 
> the last proposed patch discussion thread[2]. We want the solution to the 
> problem to land in the next stable tag: edk2-stable202005, and can submit the 
> patch.
> 
> Currently there is no clear decision on what approach to take, as there are 
> three different proposals to implement:
> 
> 1) Andrew Fish’s approach with C11-like constraint handler[3].
> 2) Marvin Häuser’s approach with return codes and constraint assertions being 
> moved to the caller side[4].
> 3) My approach suggesting DebugLib interface simplification, permitting us to 
> resolve the problem and keep backwards compatibility[5].
> 
> My personal opinion is that:
> 
> — Marvin’s way is very interesting, but it would require implementing code on 
> the caller side basically for every call, and this would requires extra 
> programming effort. It may also be uneasy to teach people how to do this 
> right, and this does not strictly provide a good solution for situations, 
> where nesting is more than 2 (i.e. when user code calls library code, which 
> itself calls library code). Because of these downsides I am afraid it is 
> impractical to adopt it in EDK II.
> — Andrew’s way is reasonable from the C standard point of view, but it does 
> not work quite right with reentrancy and I am not positive we need the 
> dynamic handling, especially because of DEBUG/RELEASE build confusion. I 
> explained this in my previous e-mail, which I attached to the end of this 
> message as quote, since groups.io  ate the previous send. 
> Other than that, I would say that I can implement this approach if there is 
> no other option.

I agree that a save restore would be required to deal with TPL issues, so my 
initial API set was incomplete and I added the extra API. 

Given every EFI driver and application is bound to its own static library 
instance managing TPL is not too problematic in a practical programming sense. 
Usually it is hardware drivers that have timer events, to manage things like 
DMA. The most common TPL usage is preventing reentrancy in the protocols, but 
in this case after a driver is loaded it is generally always called indirectly 
via its protocol APIs. It is common for applications to not run at elevated TPL 
at all. 

Thanks,

Andrew Fish

> — My own approach makes sense, as it reduces the amount of code in every 
> DebugLib and actually simplifies the development in the future. I believe 
> currently this is the most reasonable route we can take, and suggest other 
> parties to consider it.
> 
> Since the three of us each have their own suggestions, I ask Mike and others 
> to rejoin our discussions and give their opinions quickly, so that we can 
> choose, perhaps vote, and proceed with the implementation. Thanks for your 
> dedication.
> 
> Best wishes,
> Vitaly
> 
> [1] https://bugzilla.tianocore.org/show_bug.cgi?id=2054 
> 
> [2] https://edk2.groups.io/g/devel/topic/69401948 
> 
> [3] https://edk2.groups.io/g/devel/message/54520 
> 
> [4] https://edk2.groups.io/g/devel/message/54544 
> 
> [5] https://edk2.groups.io/g/devel/message/54499 
> 
> 
> 
>> Andrew,
>> 
>> I am not sure you received my message with the explanations[1], where I 
>> believe I covered the nuances, but it is nice to see you on the tune.
>> 
>> Making EDK II replicate more of the functionality from Bounds Checking Annex 
>> from C11 is an interesting idea. The historical part of our SafeStringLib is 
>> that it indeed tried to follow Microsoft's initial design (later contributed 
>> as a C standard Annex K) but completely ignored the ability to configure the 
>> handling logic. This is the problem we actually try to resolve here.
>> 
>> The reality behind this annex is, ho

Re: [edk2-devel] [PATCH v5 09/42] UefiPayloadPkg: Prepare UefiPayloadPkg to use the VmgExitLib library

[Guo Dong]

It looks good to me.
Reviewed-by: Guo Dong 

Thanks,
Guo
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Lendacky,
> Thomas
> Sent: Monday, March 2, 2020 4:07 PM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L ; Laszlo Ersek
> ; Ard Biesheuvel ; Kinney,
> Michael D ; Gao, Liming ;
> Dong, Eric ; Ni, Ray ; Brijesh Singh
> 
> Subject: [edk2-devel] [PATCH v5 09/42] UefiPayloadPkg: Prepare
> UefiPayloadPkg to use the VmgExitLib library
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> Various CpuExceptionHandlerLib libraries will updated to use the new
> VmgExitLib library. To prevent any build breakage, update the UefiPayloadPkg
> DSC files that use a form of the CpuExceptionHandlerLib library to include the
> VmgExitLib library.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Tom Lendacky 
> ---
>  UefiPayloadPkg/UefiPayloadPkgIa32.dsc| 2 ++
>  UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> index d52945442e0e..c2f7217c964e 100644
> --- a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
> @@ -233,6 +233,7 @@ [LibraryClasses.common.DXE_CORE]
> 
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.
> inf
>  !endif
> 
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuE
> xceptionHandlerLib.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
> 
>  [LibraryClasses.common.DXE_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> @@ -244,6 +245,7 @@ [LibraryClasses.common.DXE_DRIVER]
> 
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.
> inf
>  !endif
> 
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuE
> xceptionHandlerLib.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> 
>  [LibraryClasses.common.DXE_RUNTIME_DRIVER]
> diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> index 0736cd995476..b7cfeeff9b49 100644
> --- a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
> @@ -234,6 +234,7 @@ [LibraryClasses.common.DXE_CORE]
> 
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.
> inf
>  !endif
> 
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuE
> xceptionHandlerLib.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
> 
>  [LibraryClasses.common.DXE_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> @@ -245,6 +246,7 @@ [LibraryClasses.common.DXE_DRIVER]
> 
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.
> inf
>  !endif
> 
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuE
> xceptionHandlerLib.inf
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> 
>  [LibraryClasses.common.DXE_RUNTIME_DRIVER]
> --
> 2.17.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55350): https://edk2.groups.io/g/devel/message/55350
Mute This Topic: https://groups.io/mt/71687799/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

[Liming Gao]

Marvin:
  I will add this feature into next stable tag planning. Let's try to finish it 
for next stable tag. 

Thanks
Liming
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Marvin Häuser
Sent: 2020年3月4日 3:39
To: Andrew Fish ; devel@edk2.groups.io
Cc: Kinney, Michael D ; vit9696 
; Gao, Liming ; Gao, Zhichao 
; Laszlo Ersek 
Subject: Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string 
constraint assertions

Good day,

Unfortunately, this discussion has died again. This is fine by me, I'm also 
fine with the already proposed patch and mostly shared different approaches 
based on the vastly diverging feedback, but it works for us either way.

Can the patch please be reviewed and accepted for the next stable tag? 
Thanks!

Best regards,
Marvin

Am 20.02.2020 um 11:18 schrieb Marvin Häuser:
> Hey Andrew,
> 
> Thanks once again for your comments, mine are inline.
> 
> Best regards,
> Marvin
> 
> Am 20.02.2020 um 00:55 schrieb Andrew Fish:
>>
>>
>>> On Feb 17, 2020, at 12:26 AM, Marvin Häuser >> > wrote:
>>>
>>> Good day Andrew,
>>>
>>> First of all, thank you very much for putting this amount of thought 
>>> into the situation. I definitely agree with the problem you see, but 
>>> I could also live with Vitaly's proposal. However, I think you are 
>>> overcomplicating the situation a little. So, we do agree the caller 
>>> needs control of the behaviour, however your proposal needs "support"
>>> from both the caller (choose the handler) and the callee (call the
>>> handler) and is neither thread-safe nor event-safe as Vitaly already 
>>> pointed out. Fixing these problems would only worsen the complexity 
>>> situation in my opinion.
>>
>> Well EFI does not have Threads but it does have Events. I agree if an
> 
> Sorry, we were refering to the UEFI Multi-Processor services, so 
> threads in a physical sense. I think very similar concerns apply 
> regarding these services as with software multithreading in this 
> context, please correct me if I'm wrong.
> 
>> Event handler changes the constraint handler it would need to restore 
>> it so my proposal is missing an API.
>>
>> CONSTRAINT_HANDLER *
>> GetConstraintHandler (
>>     VOID
>>     )
>> {
>>     return gActiveConstraintHandler;
>> }
>>
>> You an always use the standard EFI
>>
>> It is important to remember that all the EFI images
>> (drivers/applications) are statically linked and they carry a unique 
>> instance of the Debug (or new Constraint) lib. So in your driver or 
>> App is very self contained. Also a lot of the events are phase 
>> related callbacks, and since there are no threads your drivers main 
>> thread is only really running when your driver, or app, dispatches. A 
>> lot of the callbacks are via protocols your driver publishes, but 
>> they have strict TPL rules so you can prevent reentrancy in general. 
>> So there is a lot more determinism in EFI vs. generic threaded coding.
> 
> This is true, but yet all edge-cases should be covered (event 
> "interruption", actual (processor) interrupts, Multi-Processor 
> execution), so developers do not run into unexpected (seemingly) 
> undeterministic behaviour. However, I agree it is easier to ensure for 
> something like UEFI than for a full-fledged OS of course.
> 
>>
>>>
>>> Diverging from both of your concepts entirely and keeping it very 
>>> simple, what keeps us from simply ASSERTing based on return value? 
>>> We could introduce a CONSTRAINT_ASSERT or similar, but it would be 
>>> completely different from Vitaly's proposal. It would be a caller 
>>> macro to ASSERT based on a pre-defined list of return statuses.
>>> To achieve this, we would order all statuses by types (classes). At 
>>> the moment, I can only think of two: "environmental" and 
>>> "constraint". For example, "Out Of Resources" would be environmental 
>>> and "Invalid Parameter" would be constraint. We could define 
>>> environment statuses explicitly (as it is less likely new 
>>> environment statuses are
>>> introduced) and define constraint statuses as "not environmental" 
>>> (to silently support new constraint statuses, however of course it 
>>> is a little error-prone with forwards-compatibility). As a bonus, it 
>>> forces developers to use truly appropiate error codes and correctly 
>>> propagate them from callees for this to work. :) This solution would 
>>> be backwards-compatible in a compilation sense as it can simply be a 
>>> new macro, however for its possible complexity (switch
>>> cases) I might actually prefer a function. But it would not be 
>>> backwards-compatible with the current functionality, which none of 
>>> the "caller-based" concepts can be anyway (the caller needs explicit code).
>>>
>>
>> It is an interesting idea to add granularity, but at the end of the 
>> knowledge of the correct behavior of the lower level library code 
>> really lives in code that calls this. I will admit I can see some 
>> value to making RETURN_INVALID_PARA

[edk2-devel] [PATCH v1 2/2] MdeModulePkg/Variable: Move FindVariable after AutoUpdateLangVariable

[Ming Huang]

When occur reclaim in AutoUpdateLangVariable(), the CurrPtr of Variable
is invalid. The State will be update with wrong position after
UpdateVariable in this situation and two valid PlatformLang or Lang
variables will exist. BmForEachVariable() will enter endless loop while
exist two valid PlatformLang variables. So FindVariable() should be
invoked atfer AutoUpdateLangVariable().

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang 
---
 .../Universal/Variable/RuntimeDxe/Variable.c | 26 ++--
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
index 40efa10839ad..9a20be3e581f 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -2735,6 +2735,19 @@ VariableServiceSetVariable (
 mVariableModuleGlobal->NonVolatileLastVariableOffset = (UINTN) 
NextVariable - (UINTN) Point;
   }
 
+  if (!FeaturePcdGet (PcdUefiVariableDefaultLangDeprecate)) {
+//
+// Hook the operation of setting PlatformLangCodes/PlatformLang and 
LangCodes/Lang.
+//
+Status = AutoUpdateLangVariable (VariableName, Data, DataSize);
+if (EFI_ERROR (Status)) {
+  //
+  // The auto update operation failed, directly return to avoid 
inconsistency between PlatformLang and Lang.
+  //
+  goto Done;
+}
+  }
+
   //
   // Check whether the input variable is already existed.
   //
@@ -2757,19 +2770,6 @@ VariableServiceSetVariable (
 }
   }
 
-  if (!FeaturePcdGet (PcdUefiVariableDefaultLangDeprecate)) {
-//
-// Hook the operation of setting PlatformLangCodes/PlatformLang and 
LangCodes/Lang.
-//
-Status = AutoUpdateLangVariable (VariableName, Data, DataSize);
-if (EFI_ERROR (Status)) {
-  //
-  // The auto update operation failed, directly return to avoid 
inconsistency between PlatformLang and Lang.
-  //
-  goto Done;
-}
-  }
-
   if (mVariableModuleGlobal->VariableGlobal.AuthSupport) {
 Status = AuthVariableLibProcessVariable (VariableName, VendorGuid, Data, 
DataSize, Attributes);
   } else {
-- 
2.9.5


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55354): https://edk2.groups.io/g/devel/message/55354
Mute This Topic: https://groups.io/mt/71717824/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 0/2] Fix two issue in variable

[Ming Huang]

There are two infrequent issues in variable.

Ming Huang (2):
  MdeModulePkg/Variable: Remove some debug print for runtime
  MdeModulePkg/Variable: Move FindVariable after AutoUpdateLangVariable

 .../Universal/Variable/RuntimeDxe/Variable.c | 44 ++--
 1 file changed, 21 insertions(+), 23 deletions(-)

-- 
2.9.5


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55352): https://edk2.groups.io/g/devel/message/55352
Mute This Topic: https://groups.io/mt/71717822/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 1/2] MdeModulePkg/Variable: Remove some debug print for runtime

[Ming Huang]

System will hang at debug print if enter RecordVarErrorFlag
in runtime.

This patch fix hang issue when run fwts in OS:
fwts uefirtmisc

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang 
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
index d23aea4bc712..40efa10839ad 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -278,18 +278,16 @@ RecordVarErrorFlag (
   VAR_ERROR_FLAG*VarErrFlag;
   VAR_ERROR_FLAGTempFlag;
 
-  DEBUG_CODE (
-DEBUG ((EFI_D_ERROR, "RecordVarErrorFlag (0x%02x) %s:%g - 0x%08x - 
0x%x\n", Flag, VariableName, VendorGuid, Attributes, VariableSize));
-if (Flag == VAR_ERROR_FLAG_SYSTEM_ERROR) {
-  if (AtRuntime ()) {
-DEBUG ((EFI_D_ERROR, "CommonRuntimeVariableSpace = 0x%x - 
CommonVariableTotalSize = 0x%x\n", 
mVariableModuleGlobal->CommonRuntimeVariableSpace, 
mVariableModuleGlobal->CommonVariableTotalSize));
-  } else {
+  if (!AtRuntime ()) {
+DEBUG_CODE (
+  DEBUG ((EFI_D_ERROR, "RecordVarErrorFlag (0x%02x) %s:%g - 0x%08x - 
0x%x\n", Flag, VariableName, VendorGuid, Attributes, VariableSize));
+  if (Flag == VAR_ERROR_FLAG_SYSTEM_ERROR) {
 DEBUG ((EFI_D_ERROR, "CommonVariableSpace = 0x%x - 
CommonVariableTotalSize = 0x%x\n", mVariableModuleGlobal->CommonVariableSpace, 
mVariableModuleGlobal->CommonVariableTotalSize));
+  } else {
+DEBUG ((EFI_D_ERROR, "CommonMaxUserVariableSpace = 0x%x - 
CommonUserVariableTotalSize = 0x%x\n", 
mVariableModuleGlobal->CommonMaxUserVariableSpace, 
mVariableModuleGlobal->CommonUserVariableTotalSize));
   }
-} else {
-  DEBUG ((EFI_D_ERROR, "CommonMaxUserVariableSpace = 0x%x - 
CommonUserVariableTotalSize = 0x%x\n", 
mVariableModuleGlobal->CommonMaxUserVariableSpace, 
mVariableModuleGlobal->CommonUserVariableTotalSize));
-}
-  );
+);
+  }
 
   if (!mEndOfDxe) {
 //
-- 
2.9.5


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55353): https://edk2.groups.io/g/devel/message/55353
Mute This Topic: https://groups.io/mt/71717823/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

[Ni, Ray]

Variable policy works well on protecting a whole variable.
But the BootOrder in Sunny's case may require a partial protection, which means 
portion of the variable buffer needs to be read-only.
Today's variable policy proposal doesn't take this into consideration.
If we could enhance variable policy to support partial protection, @Sunny can 
you please check whether it can meet your requirement?

The enhancement I think of is: Introduce two fields to the policy structure 
Offset and Length.
Offset (-1) indicates a whole variable protection.
Offset (>= 0) indicates a partial variable protection and the protection range 
starts from Offset with Length bytes.

This enhancement is also useful when some policy fields inside a big policy 
structure needs to be read-only.
Protecting multiple discontinuous ranges of  a variable can be achieved by 
adding multiple policy entries with different Offset/Length.


Thanks,
Ray

> -Original Message-
> From: annou...@edk2.groups.io  On Behalf Of Ni, Ray
> Sent: Friday, February 21, 2020 5:17 PM
> To: annou...@edk2.groups.io
> Subject: [edk2-announce] TianoCore Community Design Meeting Minutes - Feb 21, 
> 2020
> 
> OPEN:
>   Today's meeting is using Zoom because of the long latency using BlueJeans.
>   The URL to join meeting is changed. Make sure to check 
> https://edk2.groups.io/g/devel/calendar for details.
>   We will try Zoom for next meeting as well. If everything is good, we will 
> continue to use Zoom.
> 
> 1. Platform Libraries for Supporting UEFI Variable Resiliency (HPE)
> Presenter: Sunny Wang
> Slides:
> https://edk2.groups.io/g/devel/files/Designs/2020/0221/Platform%20Libraries%20for%20Supporting%20UEFI%20Variable%
> 20Resiliency.pdf
> 
> Problem: Support UEFI variable resiliency to compliant to security related 
> guidelines and requirements. #page 2
> 
> Locking BootOrder causes issues in OSes which is not acceptable.
> EDKII is lack of interfaces for adding platform variable protection.
> Today's presentation is to propose a solution.
> Basic rule of how variable resiliency manages BootOrder changes: #5-#6
> - Put down untrusted changes
> - Keep trusted changes
> 
> @Mike: Where is the reference data stored?
> @Sunny: In BMC.
> 
> 
> @Mike: Would like to see a small enhancement in variable policy protocol 
> proposed by Microsoft to meet your case.
> @Sunny: I checked the variable policy proposal by Microsoft. Using that might 
> be complicated.
> @Sean: We (Microsoft) have looked this. Variable hook in DXE phase not in SMM 
> is a security hole. Don't like the way of
> managing BootOrder by allowing OS to change BootOrder and reverting. Boot 
> may contain critical data for OS and
> reverting that may cause troubles.
> @Sunny: I cannot think of solutions for OS runtime change.
> 
> 
> @Mike: I would break the big problem to 3 smaller ones:
>1. variable data corruption
> It requires a way to detect corruption and recovery.
>2. critical platform variables
> It usually requires a lock mechanism and variable policy proposal is 
> more general for this protection.
>3. UEFI variables with multiple producers
> How to protect them could be a topic for USWG.
> @Sean: The scope of the problem discussed in this presentation is huge. Can a 
> platform module run at a different point of
> time to manage the variable storage instead of using hook way?
> @Sunny: BootOrder is just one of the variables that need protection.
> 
> 
> @Mike: Using a separate platform module might be better because it will also 
> check the variables not changed by
> firmware.
> @Sean: PEI modules may access the wrong data modified by untrusted entity.
> @Ray: Is the protection based on not just the variable GUID/name, but also 
> who requests the change?
> @Sunny: Yes. Following sides (#page 10+) will talk about protection from 
> non-trusted entity.
> @Ray: Let's move to email discussion first. Identify the scope of the problem 
> first.
> 
> Thanks,
> Ray
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55355): https://edk2.groups.io/g/devel/message/55355
Mute This Topic: https://groups.io/mt/71718822/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

[Wang, Sunny (HPS SW)]

Sorry for not making any progress since last meeting.
Sure! I will work on enhancing the variable policy to support partial 
protection and recovery. However, the update will be late because I need to 
first deal with other urgent stuff.
By the way, thanks for giving a lot of valuable comments at our offline 
discussion, Ray.  :)

Regards,
Sunny Wang

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ni, Ray
Sent: Wednesday, March 4, 2020 11:46 AM
To: Sean Brogan ; Kinney, Michael D 
; Wang, Sunny (HPS SW) 
Cc: Ni, Ray ; devel@edk2.groups.io
Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 
2020

Variable policy works well on protecting a whole variable.
But the BootOrder in Sunny's case may require a partial protection, which means 
portion of the variable buffer needs to be read-only.
Today's variable policy proposal doesn't take this into consideration.
If we could enhance variable policy to support partial protection, @Sunny can 
you please check whether it can meet your requirement?

The enhancement I think of is: Introduce two fields to the policy structure 
Offset and Length.
Offset (-1) indicates a whole variable protection.
Offset (>= 0) indicates a partial variable protection and the protection range 
starts from Offset with Length bytes.

This enhancement is also useful when some policy fields inside a big policy 
structure needs to be read-only.
Protecting multiple discontinuous ranges of  a variable can be achieved by 
adding multiple policy entries with different Offset/Length.


Thanks,
Ray

> -Original Message-
> From: annou...@edk2.groups.io  On Behalf Of 
> Ni, Ray
> Sent: Friday, February 21, 2020 5:17 PM
> To: annou...@edk2.groups.io
> Subject: [edk2-announce] TianoCore Community Design Meeting Minutes - 
> Feb 21, 2020
> 
> OPEN:
>   Today's meeting is using Zoom because of the long latency using BlueJeans.
>   The URL to join meeting is changed. Make sure to check 
> https://edk2.groups.io/g/devel/calendar  for details.
>   We will try Zoom for next meeting as well. If everything is good, we will 
> continue to use Zoom.
> 
> 1. Platform Libraries for Supporting UEFI Variable Resiliency (HPE)
> Presenter: Sunny Wang
> Slides:
> INVALID URI REMOVED
> devel_files_Designs_2020_0221_Platform-2520Libraries-2520for-2520Suppo
> rting-2520UEFI-2520Variable-25&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9c
> LgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=U5okqrn3H585vxU4GwALnIBwi0s
> 0dQ0hYIDuFj2z-4Y&s=oG0quXKBZu3XD7Drm04CsF445C8kfOGOJGzeqACJxAA&e=
> 20Resiliency.pdf
> 
> Problem: Support UEFI variable resiliency to compliant to security 
> related guidelines and requirements. #page 2
> 
> Locking BootOrder causes issues in OSes which is not acceptable.
> EDKII is lack of interfaces for adding platform variable protection.
> Today's presentation is to propose a solution.
> Basic rule of how variable resiliency manages BootOrder changes: #5-#6
> - Put down untrusted changes
> - Keep trusted changes
> 
> @Mike: Where is the reference data stored?
> @Sunny: In BMC.
> 
> 
> @Mike: Would like to see a small enhancement in variable policy protocol 
> proposed by Microsoft to meet your case.
> @Sunny: I checked the variable policy proposal by Microsoft. Using that might 
> be complicated.
> @Sean: We (Microsoft) have looked this. Variable hook in DXE phase not 
> in SMM is a security hole. Don't like the way of managing BootOrder by 
> allowing OS to change BootOrder and reverting. Boot may contain critical 
> data for OS and reverting that may cause troubles.
> @Sunny: I cannot think of solutions for OS runtime change.
> 
> 
> @Mike: I would break the big problem to 3 smaller ones:
>1. variable data corruption
> It requires a way to detect corruption and recovery.
>2. critical platform variables
> It usually requires a lock mechanism and variable policy proposal is 
> more general for this protection.
>3. UEFI variables with multiple producers
> How to protect them could be a topic for USWG.
> @Sean: The scope of the problem discussed in this presentation is 
> huge. Can a platform module run at a different point of time to manage the 
> variable storage instead of using hook way?
> @Sunny: BootOrder is just one of the variables that need protection.
> 
> 
> @Mike: Using a separate platform module might be better because it 
> will also check the variables not changed by firmware.
> @Sean: PEI modules may access the wrong data modified by untrusted entity.
> @Ray: Is the protection based on not just the variable GUID/name, but also 
> who requests the change?
> @Sunny: Yes. Following sides (#page 10+) will talk about protection from 
> non-trusted entity.
> @Ray: Let's move to email discussion first. Identify the scope of the problem 
> first.
> 
> Thanks,
> Ray
> 
> 





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55356): h

[edk2-devel] EDK II Stable Tag edk2-stable202002 will be created based on commit 4c0f6e349d32cf27a7104ddd3e729d6ebc88ea70

[Liming Gao]

Hi, all
edk2-stable202002 tag will be created on Mar 4th (UTC-8 00:00:00). It will base 
on current edk2 trunk (the latest commit 
https://github.com/tianocore/edk2/commit/4c0f6e349d32cf27a7104ddd3e729d6ebc88ea70
 UefiCpuPkg/MpInitLib: Skip reading PlatformId on AMD processors). If you have 
any comments, please reply the mail. If no concern or objection, I will create 
tag and send another announce mail that edk2-stable202002 is completed and 
normal commit is resumed.

Thanks
Liming

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55357): https://edk2.groups.io/g/devel/message/55357
Mute This Topic: https://groups.io/mt/71719523/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2/master PATCH RISC-V CI v1 0/6] RISC-V EDK2 CI configuration files.

[Abner Chang]

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

This set of patches enale RISC-V architecture on EDK2 CI test process.
The external dependency of toolchain for RISCV64 architecture is retrieved from:
https://media.githubusercontent.com/media/riscv/riscv-uefi-edk2-docs/master/gcc-riscv-edk2-ci-toolchain/.

Signed-off-by: Abner Chang 

Cc: Bret Barkelew 
Cc: Sean Brogan 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Gilbert Chen 
Cc: Daniel Helmut Schaefer 

Abner Chang (6):
  RiscVPlatformPkg: Add RiscVPlatformPkg yaml file for EDK2 CI.
  RiscVPkg: Add RiscVPkg yaml file for EDK2 CI.
  MdeModulePkg: Revise MdeModulePkg yaml file for RISC-V EDK2 CI.
  BaseTools: Enable RISC-V architecture for RISC-V EDK2 CI.
  .azurepipelines: Add RISC-V architecture on RISC-V EDK2 CI.
  .pytool: Add RISC-V architecture on RISC-V EDK2 CI.

 .azurepipelines/Ubuntu-GCC5.yml   |  3 +-
 .pytool/CISettings.py | 15 +++-
 .../Bin/gcc_riscv64_unknown_ext_dep.yaml  | 21 +
 .../LinuxGcc5ToolChain/LinuxGcc5ToolChain.py  | 31 +++
 MdeModulePkg/MdeModulePkg.ci.yaml |  4 +-
 RiscVPkg/RiscVPkg.ci.yaml | 80 ++
 RiscVPlatformPkg/RiscVPlatformPkg.ci.yaml | 81 +++
 7 files changed, 230 insertions(+), 5 deletions(-)
 create mode 100644 BaseTools/Bin/gcc_riscv64_unknown_ext_dep.yaml
 create mode 100644 RiscVPkg/RiscVPkg.ci.yaml
 create mode 100644 RiscVPlatformPkg/RiscVPlatformPkg.ci.yaml

-- 
2.25.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55358): https://edk2.groups.io/g/devel/message/55358
Mute This Topic: https://groups.io/mt/71720420/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2/master PATCH RISC-V CI v1 3/6] MdeModulePkg: Revise MdeModulePkg yaml file for RISC-V EDK2 CI.

[Abner Chang]

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

Revise yaml file for EDK2 CI testing on RISC-V architecture.

Signed-off-by: Abner Chang 

Cc: Bret Barkelew 
Cc: Sean Brogan 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Gilbert Chen 
Cc: Daniel Helmut Schaefer 
---
 MdeModulePkg/MdeModulePkg.ci.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/MdeModulePkg.ci.yaml 
b/MdeModulePkg/MdeModulePkg.ci.yaml
index 3b6e747075..d957af68fc 100644
--- a/MdeModulePkg/MdeModulePkg.ci.yaml
+++ b/MdeModulePkg/MdeModulePkg.ci.yaml
@@ -2,6 +2,7 @@
 # CI configuration for MdeModulePkg
 #
 # Copyright (c) Microsoft Corporation
+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
 {
@@ -25,7 +26,8 @@
 "MdePkg/MdePkg.dec",
 "MdeModulePkg/MdeModulePkg.dec",
 "StandaloneMmPkg/StandaloneMmPkg.dec",
-"ArmPkg/ArmPkg.dec"  # this should be fixed by promoting an 
abstraction
+"ArmPkg/ArmPkg.dec",  # this should be fixed by promoting an 
abstraction
+"RiscVPkg/RiscVPkg.dec" # this should be fixed by promoting an 
abstraction
 ],
 # For host based unit tests
 "AcceptableDependencies-HOST_APPLICATION":[
-- 
2.25.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55361): https://edk2.groups.io/g/devel/message/55361
Mute This Topic: https://groups.io/mt/71720427/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2/master PATCH RISC-V CI v1 5/6] .azurepipelines: Add RISC-V architecture on RISC-V EDK2 CI.

[Abner Chang]

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

Add RISC-V architecture on RISC-V EDK2 CI.

Signed-off-by: Abner Chang 

Cc: Bret Barkelew 
Cc: Sean Brogan 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Gilbert Chen 
Cc: Daniel Helmut Schaefer 
---
 .azurepipelines/Ubuntu-GCC5.yml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/.azurepipelines/Ubuntu-GCC5.yml b/.azurepipelines/Ubuntu-GCC5.yml
index a26a3a2cb2..7cd67c98da 100644
--- a/.azurepipelines/Ubuntu-GCC5.yml
+++ b/.azurepipelines/Ubuntu-GCC5.yml
@@ -2,6 +2,7 @@
 # Azure Pipeline build file for a build using ubuntu and GCC5
 #
 # Copyright (c) Microsoft Corporation.
+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
 trigger:
@@ -14,5 +15,5 @@ jobs:
   parameters:
 tool_chain_tag: 'GCC5'
 vm_image: 'ubuntu-latest'
-arch_list: "IA32,X64,ARM,AARCH64"
+arch_list: "IA32,X64,ARM,AARCH64,RISCV64"
 
-- 
2.25.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55363): https://edk2.groups.io/g/devel/message/55363
Mute This Topic: https://groups.io/mt/71720430/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2/master PATCH RISC-V CI v1 1/6] RiscVPlatformPkg: Add RiscVPlatformPkg yaml file for EDK2 CI.

[Abner Chang]

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

Add yaml file for EDK2 CI testing on RiscVPlatformPkg.

Signed-off-by: Abner Chang 

Cc: Bret Barkelew 
Cc: Sean Brogan 
Cc: Leif Lindholm 
Cc: Gilbert Chen 
Cc: Daniel Helmut Schaefer 
---
 RiscVPlatformPkg/RiscVPlatformPkg.ci.yaml | 81 +++
 1 file changed, 81 insertions(+)
 create mode 100644 RiscVPlatformPkg/RiscVPlatformPkg.ci.yaml

diff --git a/RiscVPlatformPkg/RiscVPlatformPkg.ci.yaml 
b/RiscVPlatformPkg/RiscVPlatformPkg.ci.yaml
new file mode 100644
index 00..669874a028
--- /dev/null
+++ b/RiscVPlatformPkg/RiscVPlatformPkg.ci.yaml
@@ -0,0 +1,81 @@
+## @file
+# CI configuration for RiscVPlatformPkg
+#
+# Copyright (c) Microsoft Corporation
+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+{
+## options defined ci/Plugin/CompilerPlugin
+"CompilerPlugin": {
+"DscPath": "RiscVPlatformPkg.dsc"
+},
+## options defined ci/Plugin/HostUnitTestCompilerPlugin
+"HostUnitTestCompilerPlugin": {
+},
+
+## options defined ci/Plugin/CharEncodingCheck
+"CharEncodingCheck": {
+"IgnoreFiles": []
+},
+
+## options defined ci/Plugin/DependencyCheck
+"DependencyCheck": {
+"AcceptableDependencies": [
+"MdePkg/MdePkg.dec",
+"MdeModulePkg/MdeModulePkg.dec",
+"RiscVPkg/RiscVPkg.dec",
+"RiscVPlatformPkg/RiscVPlatformPkg.dec"
+],
+# For host based unit tests
+"AcceptableDependencies-HOST_APPLICATION":[],
+# For UEFI shell based apps
+"AcceptableDependencies-UEFI_APPLICATION":[],
+"IgnoreInf": []
+},
+
+## options defined ci/Plugin/DscCompleteCheck
+"DscCompleteCheck": {
+"IgnoreInf": [],
+"DscPath": "RiscVPlatformPkg.dsc"
+},
+## options defined ci/Plugin/HostUnitTestDscCompleteCheck
+"HostUnitTestDscCompleteCheck": {
+},
+
+## options defined ci/Plugin/GuidCheck
+"GuidCheck": {
+"IgnoreGuidName": [],
+"IgnoreGuidValue": ["----"],
+"IgnoreFoldersAndFiles": [],
+"IgnoreDuplicates": []
+},
+
+## options defined ci/Plugin/LibraryClassCheck
+"LibraryClassCheck": {
+"IgnoreHeaderFile": []
+},
+
+## options defined ci/Plugin/SpellCheck
+"SpellCheck": {
+"AuditOnly": True,   # Fails test but run in AuditOnly mode to 
collect log
+"IgnoreStandardPaths": [ # Standard Plugin defined paths that 
should be ignore
+"*.c", "*.h", "*.s", "*.asl", "*.inf"
+],
+"IgnoreFiles": [],
+"ExtendWords": [   # words to extend to the dictionary for 
this package
+"LIGHTGRAY",
+"DARKGRAY",
+"LIGHTBLUE",
+"LIGHTGREEN",
+"LIGHTCYAN",
+"LIGHTRED",
+"LIGHTMAGENTA",
+"FVMAIN",
+"VARCHECKPCD",
+"Getxx",
+"lzturbo"
+],
+"AdditionalIncludePaths": [] # Additional paths to spell check 
relative to package root (wildcards supported)
+}
+}
-- 
2.25.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55359): https://edk2.groups.io/g/devel/message/55359
Mute This Topic: https://groups.io/mt/71720421/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2/master PATCH RISC-V CI v1 2/6] RiscVPkg: Add RiscVPkg yaml file for EDK2 CI.

[Abner Chang]

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

Add yaml file for EDK2 CI testing on RiscVPkg.

Signed-off-by: Abner Chang 

Cc: Bret Barkelew 
Cc: Sean Brogan 
Cc: Leif Lindholm 
Cc: Gilbert Chen 
Cc: Daniel Helmut Schaefer 
---
 RiscVPkg/RiscVPkg.ci.yaml | 80 +++
 1 file changed, 80 insertions(+)
 create mode 100644 RiscVPkg/RiscVPkg.ci.yaml

diff --git a/RiscVPkg/RiscVPkg.ci.yaml b/RiscVPkg/RiscVPkg.ci.yaml
new file mode 100644
index 00..74a42cd59c
--- /dev/null
+++ b/RiscVPkg/RiscVPkg.ci.yaml
@@ -0,0 +1,80 @@
+## @file
+# CI configuration for RiscVPkg
+#
+# Copyright (c) Microsoft Corporation
+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+{
+## options defined ci/Plugin/CompilerPlugin
+"CompilerPlugin": {
+"DscPath": "RiscVPkg.dsc"
+},
+## options defined ci/Plugin/HostUnitTestCompilerPlugin
+"HostUnitTestCompilerPlugin": {
+},
+
+## options defined ci/Plugin/CharEncodingCheck
+"CharEncodingCheck": {
+"IgnoreFiles": []
+},
+
+## options defined ci/Plugin/DependencyCheck
+"DependencyCheck": {
+"AcceptableDependencies": [
+"MdePkg/MdePkg.dec",
+"MdeModulePkg/MdeModulePkg.dec",
+"EmbeddedPkg/EmbeddedPkg.dec",
+"RiscVPkg/RiscVPkg.dec"
+],
+# For host based unit tests
+"AcceptableDependencies-HOST_APPLICATION":[],
+# For UEFI shell based apps
+"AcceptableDependencies-UEFI_APPLICATION":[],
+"IgnoreInf": []
+},
+
+## options defined ci/Plugin/DscCompleteCheck
+"DscCompleteCheck": {
+"IgnoreInf": [],
+"DscPath": "RiscVPkg.dsc"
+},
+## options defined ci/Plugin/HostUnitTestDscCompleteCheck
+"HostUnitTestDscCompleteCheck": {},
+
+## options defined ci/Plugin/GuidCheck
+"GuidCheck": {
+"IgnoreGuidName": [],
+"IgnoreGuidValue": ["----"],
+"IgnoreFoldersAndFiles": [],
+"IgnoreDuplicates": []
+},
+
+## options defined ci/Plugin/LibraryClassCheck
+"LibraryClassCheck": {
+"IgnoreHeaderFile": []
+},
+
+## options defined ci/Plugin/SpellCheck
+"SpellCheck": {
+"AuditOnly": True,   # Fails test but run in AuditOnly mode to 
collect log
+"IgnoreStandardPaths": [ # Standard Plugin defined paths that 
should be ignore
+"*.c", "*.h", "*.s", "*.asl", "*.inf"
+],
+"IgnoreFiles": [],
+"ExtendWords": [   # words to extend to the dictionary for 
this package
+"LIGHTGRAY",
+"DARKGRAY",
+"LIGHTBLUE",
+"LIGHTGREEN",
+"LIGHTCYAN",
+"LIGHTRED",
+"LIGHTMAGENTA",
+"FVMAIN",
+"VARCHECKPCD",
+"Getxx",
+"lzturbo"
+],
+"AdditionalIncludePaths": [] # Additional paths to spell check 
relative to package root (wildcards supported)
+}
+}
-- 
2.25.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55360): https://edk2.groups.io/g/devel/message/55360
Mute This Topic: https://groups.io/mt/71720423/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2/master PATCH RISC-V CI v1 6/6] .pytool: Add RISC-V architecture on RISC-V EDK2 CI.

[Abner Chang]

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

Add RISC-V architecture on RISC-V EDK2 CI testing.

Signed-off-by: Abner Chang 

Cc: Bret Barkelew 
Cc: Sean Brogan 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Gilbert Chen 
Cc: Daniel Helmut Schaefer 
---
 .pytool/CISettings.py | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/.pytool/CISettings.py b/.pytool/CISettings.py
index 79593d9dc5..2ef55e366d 100644
--- a/.pytool/CISettings.py
+++ b/.pytool/CISettings.py
@@ -1,6 +1,7 @@
 # @file
 #
 # Copyright (c) Microsoft Corporation.
+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
 import os
@@ -49,15 +50,19 @@ class Settings(CiBuildSettingsManager, 
UpdateSettingsManager, SetupSettingsManag
 "ShellPkg",
 "FatPkg",
 "CryptoPkg",
-"UnitTestFrameworkPkg"
+"UnitTestFrameworkPkg",
+"RiscVPkg",
+"RiscVPlatformPkg"
 )
 
 def GetArchitecturesSupported(self):
 ''' return iterable of edk2 architectures supported by this build '''
-return ("IA32",
+return (
+"IA32",
 "X64",
 "ARM",
-"AARCH64")
+"AARCH64",
+"RISCV64")
 
 def GetTargetsSupported(self):
 ''' return iterable of edk2 target tags supported by this build '''
@@ -130,6 +135,8 @@ class Settings(CiBuildSettingsManager, 
UpdateSettingsManager, SetupSettingsManag
 scopes += ("gcc_aarch64_linux",)
 if "ARM" in self.ActualArchitectures:
 scopes += ("gcc_arm_linux",)
+if "RISCV64" in self.ActualArchitectures:
+scopes += ("gcc_riscv64_unknown",)
 
 return scopes
 
@@ -144,6 +151,8 @@ class Settings(CiBuildSettingsManager, 
UpdateSettingsManager, SetupSettingsManag
 "CryptoPkg/Library/OpensslLib/openssl", False))
 rs.append(RequiredSubmodule(
 "UnitTestFrameworkPkg/Library/CmockaLib/cmocka", False))
+rs.append(RequiredSubmodule(
+"RiscVPkg/Library/RiscVOpensbiLib/opensbi", False))
 return rs
 
 def GetName(self):
-- 
2.25.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55364): https://edk2.groups.io/g/devel/message/55364
Mute This Topic: https://groups.io/mt/71720432/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2/master PATCH RISC-V CI v1 4/6] BaseTools: Enable RISC-V architecture for RISC-V EDK2 CI.

[Abner Chang]

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

EDK CI for RISC-V architecture

Enable RISC-V architecture for RISC-V EDK2 CI testing.

Signed-off-by: Abner Chang 

Cc: Bret Barkelew 
Cc: Sean Brogan 
Cc: Bob Feng 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Gilbert Chen 
Cc: Daniel Helmut Schaefer 
---
 .../Bin/gcc_riscv64_unknown_ext_dep.yaml  | 21 +
 .../LinuxGcc5ToolChain/LinuxGcc5ToolChain.py  | 31 +++
 2 files changed, 52 insertions(+)
 create mode 100644 BaseTools/Bin/gcc_riscv64_unknown_ext_dep.yaml

diff --git a/BaseTools/Bin/gcc_riscv64_unknown_ext_dep.yaml 
b/BaseTools/Bin/gcc_riscv64_unknown_ext_dep.yaml
new file mode 100644
index 00..38fe300a68
--- /dev/null
+++ b/BaseTools/Bin/gcc_riscv64_unknown_ext_dep.yaml
@@ -0,0 +1,21 @@
+## @file
+# Download GCC RISCV64 compiler from RISC-V Organization release site
+# Set shell variable GCC5_RISCV64_INSTALL to this folder
+#
+# This is only downloaded when a build activates scope gcc_riscv64_unknown
+#
+# Copyright (c) Microsoft Corporation.
+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+{
+  "scope": "gcc_riscv64_unknown",
+  "type": "web",
+  "name": "gcc_riscv64_unknown",
+  "source": 
"https://media.githubusercontent.com/media/riscv/riscv-uefi-edk2-docs/master/gcc-riscv-edk2-ci-toolchain/gcc-riscv-9.2.0-2020.02-x86_64_riscv64-unknown-gnu.tar.xz";,
+  "version": "9.2.0",
+  "compression_type": "tar",
+  "internal_path": "/gcc-riscv-9.2.0-2020.02-x86_64_riscv64-unknown-gnu",
+  "flags": ["set_shell_var", ],
+  "var_name": "GCC5_RISCV64_INSTALL"
+}
diff --git a/BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain.py 
b/BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain.py
index c31641e931..502d2c21d2 100644
--- a/BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain.py
+++ b/BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain.py
@@ -4,6 +4,7 @@
 # This plugin works in conjuncture with the tools_def
 #
 # Copyright (c) Microsoft Corporation
+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
 import os
@@ -36,6 +37,12 @@ class LinuxGcc5ToolChain(IUefiBuildPlugin):
 self.Logger.critical("Failed in check arm")
 return ret
 
+# Check RISCV64 compiler
+ret = self._check_riscv64()
+if ret != 0:
+self.Logger.critical("Failed in check riscv64")
+return ret
+
 return 0
 
 def _check_arm(self):
@@ -83,3 +90,27 @@ class LinuxGcc5ToolChain(IUefiBuildPlugin):
 return -2
 
 return 0
+
+def _check_riscv64(self):
+# check to see if full path already configured
+if 
shell_environment.GetEnvironment().get_shell_var("GCC5_RISCV64_PREFIX") is not 
None:
+self.Logger.info("GCC5_RISCV64_PREFIX is already set.")
+
+else:
+# now check for install dir.  If set then set the Prefix
+install_path = shell_environment.GetEnvironment(
+).get_shell_var("GCC5_RISCV64_INSTALL")
+if install_path is None:
+return 0
+
+# make GCC5_RISCV64_PREFIX to align with tools_def.txt
+prefix = os.path.join(install_path, "bin", "riscv64-unknown-elf-")
+
shell_environment.GetEnvironment().set_shell_var("GCC5_RISCV64_PREFIX", prefix)
+
+# now confirm it exists
+if not 
os.path.exists(shell_environment.GetEnvironment().get_shell_var("GCC5_RISCV64_PREFIX")
 + "gcc"):
+self.Logger.error(
+"Path for GCC5_RISCV64_PREFIX toolchain is invalid")
+return -2
+
+return 0
-- 
2.25.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55362): https://edk2.groups.io/g/devel/message/55362
Mute This Topic: https://groups.io/mt/71720429/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

[Ni, Ray]

Sunny,
Let's discuss in this week's meeting to see whether the below enhancement 
proposal can be aligned first.

Thanks,
Ray

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Wang, Sunny 
> (HPS SW)
> Sent: Wednesday, March 4, 2020 12:12 PM
> To: devel@edk2.groups.io; Ni, Ray ; Sean Brogan 
> ; Kinney, Michael D
> 
> Cc: Wang, Sunny (HPS SW) ; Wei, Kent (HPS SW) 
> ; Spottswood, Jason
> 
> Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 
> 21, 2020
> 
> Sorry for not making any progress since last meeting.
> Sure! I will work on enhancing the variable policy to support partial 
> protection and recovery. However, the update will be
> late because I need to first deal with other urgent stuff.
> By the way, thanks for giving a lot of valuable comments at our offline 
> discussion, Ray.  :)
> 
> Regards,
> Sunny Wang
> 
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ni, Ray
> Sent: Wednesday, March 4, 2020 11:46 AM
> To: Sean Brogan ; Kinney, Michael D 
> ; Wang, Sunny (HPS SW)
> 
> Cc: Ni, Ray ; devel@edk2.groups.io
> Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 
> 21, 2020
> 
> Variable policy works well on protecting a whole variable.
> But the BootOrder in Sunny's case may require a partial protection, which 
> means portion of the variable buffer needs to
> be read-only.
> Today's variable policy proposal doesn't take this into consideration.
> If we could enhance variable policy to support partial protection, @Sunny can 
> you please check whether it can meet your
> requirement?
> 
> The enhancement I think of is: Introduce two fields to the policy structure 
> Offset and Length.
> Offset (-1) indicates a whole variable protection.
> Offset (>= 0) indicates a partial variable protection and the protection 
> range starts from Offset with Length bytes.
> 
> This enhancement is also useful when some policy fields inside a big policy 
> structure needs to be read-only.
> Protecting multiple discontinuous ranges of  a variable can be achieved by 
> adding multiple policy entries with different
> Offset/Length.
> 
> 
> Thanks,
> Ray
> 
> > -Original Message-
> > From: annou...@edk2.groups.io  On Behalf Of
> > Ni, Ray
> > Sent: Friday, February 21, 2020 5:17 PM
> > To: annou...@edk2.groups.io
> > Subject: [edk2-announce] TianoCore Community Design Meeting Minutes -
> > Feb 21, 2020
> >
> > OPEN:
> >   Today's meeting is using Zoom because of the long latency using BlueJeans.
> >   The URL to join meeting is changed. Make sure to check 
> > https://edk2.groups.io/g/devel/calendar  for details.
> >   We will try Zoom for next meeting as well. If everything is good, we will 
> > continue to use Zoom.
> >
> > 1. Platform Libraries for Supporting UEFI Variable Resiliency (HPE)
> > Presenter: Sunny Wang
> > Slides:
> > INVALID URI REMOVED
> > devel_files_Designs_2020_0221_Platform-2520Libraries-2520for-2520Suppo
> > rting-2520UEFI-2520Variable-25&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9c
> > LgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=U5okqrn3H585vxU4GwALnIBwi0s
> > 0dQ0hYIDuFj2z-4Y&s=oG0quXKBZu3XD7Drm04CsF445C8kfOGOJGzeqACJxAA&e=
> > 20Resiliency.pdf
> >
> > Problem: Support UEFI variable resiliency to compliant to security
> > related guidelines and requirements. #page 2
> >
> > Locking BootOrder causes issues in OSes which is not acceptable.
> > EDKII is lack of interfaces for adding platform variable protection.
> > Today's presentation is to propose a solution.
> > Basic rule of how variable resiliency manages BootOrder changes: #5-#6
> > - Put down untrusted changes
> > - Keep trusted changes
> >
> > @Mike: Where is the reference data stored?
> > @Sunny: In BMC.
> >
> > 
> > @Mike: Would like to see a small enhancement in variable policy protocol 
> > proposed by Microsoft to meet your case.
> > @Sunny: I checked the variable policy proposal by Microsoft. Using that 
> > might be complicated.
> > @Sean: We (Microsoft) have looked this. Variable hook in DXE phase not
> > in SMM is a security hole. Don't like the way of managing BootOrder by
> > allowing OS to change BootOrder and reverting. Boot may contain 
> > critical data for OS and reverting that may cause
> troubles.
> > @Sunny: I cannot think of solutions for OS runtime change.
> >
> > 
> > @Mike: I would break the big problem to 3 smaller ones:
> >1. variable data corruption
> > It requires a way to detect corruption and recovery.
> >2. critical platform variables
> > It usually requires a lock mechanism and variable policy proposal 
> > is more general for this protection.
> >3. UEFI variables with multiple producers
> > How to protect them could be a topic for USWG.
> > @Sean: The scope of the problem discussed in this presentation is
> > huge. Can a platform module run at a different point of time to manage the 
> > variable storage instead of using hook way?
> > @Sunny: B

[edk2-devel] [PATCH edk2-platforms 1/1] DeveloperBox: implement measured boot

[Ard Biesheuvel]

Enable the various components, library class resolutions and PCD defaults
to enable measured boot based on a version 2 TPM. The TPM is exposed as
having a memory mapped TIS frame, which is accomplished using the SPI
command sequencer that is available on this platform. Note that this
requires SCP firmware support.

Signed-off-by: Ard Biesheuvel 
---
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc   
   | 91 
 Platform/Socionext/DeveloperBox/DeveloperBox.fdf   
   | 11 +++
 Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
   |  4 +
 Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi  
   |  7 ++
 Silicon/Socionext/SynQuacer/Include/Platform/MemoryMap.h   
   |  4 +
 
Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.c
 |  3 +
 6 files changed, 120 insertions(+)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 9f8cb68cdd26..cddd34e65389 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -24,6 +24,7 @@ [Defines]
 
   DEFINE DEBUG_ON_UART1  = FALSE
   DEFINE SECURE_BOOT_ENABLE  = FALSE
+  DEFINE TPM2_ENABLE = FALSE
   DEFINE X64EMU_ENABLE   = FALSE
 
 !include Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
@@ -38,6 +39,16 @@ [LibraryClasses]
   PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
 !endif
 
+!if $(TPM2_ENABLE) == TRUE
+  Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
+  
Tcg2PhysicalPresenceLib|SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
+  
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
+  
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
+!else
+  
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
+  
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+!endif
+
 [LibraryClasses.common.SEC]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
@@ -60,6 +71,19 @@ [LibraryClasses.common.PEIM]
   PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
   
MemoryInitPeiLib|Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.inf
   
PlatformPeiLib|Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformPeiLib/SynQuacerPlatformPeiLib.inf
+  ResetSystemLib|MdeModulePkg/Library/PeiResetSystemLib/PeiResetSystemLib.inf
+
+!if $(TPM2_ENABLE) == TRUE
+  Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12DeviceLibDTpm.inf
+  Tpm12CommandLib|SecurityPkg/Library/Tpm12CommandLib/Tpm12CommandLib.inf
+
+  Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
+  Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
+  
Tcg2PhysicalPresenceLib|SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
+  
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
+
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
+!endif
 
 [LibraryClasses.common.DXE_CORE]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
@@ -92,6 +116,10 @@ [LibraryClasses.common.DXE_DRIVER]
   
PciHostBridgeLib|Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf
   
NonDiscoverableDeviceRegistrationLib|MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/NonDiscoverableDeviceRegistrationLib.inf
 
+!if $(TPM2_ENABLE) == TRUE
+  Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
+!endif
+
 [LibraryClasses.common.UEFI_APPLICATION]
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
@@ -183,13 +211,33 @@ [PcdsFixedAtBuild]
   gEfiSecurityPkgTokenSpaceGuid.PcdFixedMediaImageVerificationPolicy|0x04
   gEfiSecurityPkgTokenSpaceGuid.PcdRemovableMediaImageVerificationPolicy|0x04
 
+!if $(TPM2_ENABLE) == TRUE
+  gEfiSecurityPkgTokenSpaceGuid.PcdTpmBaseAddress|0x1000
+!endif
+
 [PcdsDynamicExDefault.common.DEFAULT]
   
gEfiSignedCapsulePkgTokenSpaceGuid.PcdEdkiiSystemFirmwareImageDescriptor|{0x0}|VOID*|0x100
   gEfiSignedCapsulePkgTokenSpaceGuid.PcdEdkiiSystemFirmwareFileGuid|{0xf7, 
0x89, 0x9b, 0xe9, 0x20, 0xc1, 0x25, 0x4b, 0x4d, 0xb1, 0x83, 0x94, 0xed, 0xb0, 
0xb4, 0xf5}
 
+!if $(TPM2_ENABLE) == TRUE
+  gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
+  gEfiSecurityPkgTokenSpaceGuid.PcdTpm2InitializationPolicy|1
+  gEfiSecurityPkgTokenSpaceGuid.PcdTpm2SelfTestPolicy

Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020

[Wang, Sunny (HPS SW)]

Sure!

Regards,
Sunny Wang

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ni, Ray
Sent: Wednesday, March 4, 2020 3:26 PM
To: devel@edk2.groups.io; Wang, Sunny (HPS SW) ; Sean Brogan 
; Kinney, Michael D 
Cc: Wei, Kent (HPS SW) ; Spottswood, Jason 

Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 
2020

Sunny,
Let's discuss in this week's meeting to see whether the below enhancement 
proposal can be aligned first.

Thanks,
Ray

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Wang, 
> Sunny (HPS SW)
> Sent: Wednesday, March 4, 2020 12:12 PM
> To: devel@edk2.groups.io; Ni, Ray ; Sean Brogan 
> ; Kinney, Michael D 
> 
> Cc: Wang, Sunny (HPS SW) ; Wei, Kent (HPS SW) 
> ; Spottswood, Jason 
> Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - 
> Feb 21, 2020
> 
> Sorry for not making any progress since last meeting.
> Sure! I will work on enhancing the variable policy to support partial 
> protection and recovery. However, the update will be late because I need to 
> first deal with other urgent stuff.
> By the way, thanks for giving a lot of valuable comments at our 
> offline discussion, Ray.  :)
> 
> Regards,
> Sunny Wang
> 
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Ni, Ray
> Sent: Wednesday, March 4, 2020 11:46 AM
> To: Sean Brogan ; Kinney, Michael D 
> ; Wang, Sunny (HPS SW) 
> Cc: Ni, Ray ; devel@edk2.groups.io
> Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - 
> Feb 21, 2020
> 
> Variable policy works well on protecting a whole variable.
> But the BootOrder in Sunny's case may require a partial protection, 
> which means portion of the variable buffer needs to be read-only.
> Today's variable policy proposal doesn't take this into consideration.
> If we could enhance variable policy to support partial protection, 
> @Sunny can you please check whether it can meet your requirement?
> 
> The enhancement I think of is: Introduce two fields to the policy structure 
> Offset and Length.
> Offset (-1) indicates a whole variable protection.
> Offset (>= 0) indicates a partial variable protection and the protection 
> range starts from Offset with Length bytes.
> 
> This enhancement is also useful when some policy fields inside a big policy 
> structure needs to be read-only.
> Protecting multiple discontinuous ranges of  a variable can be 
> achieved by adding multiple policy entries with different Offset/Length.
> 
> 
> Thanks,
> Ray
> 
> > -Original Message-
> > From: annou...@edk2.groups.io  On Behalf Of 
> > Ni, Ray
> > Sent: Friday, February 21, 2020 5:17 PM
> > To: annou...@edk2.groups.io
> > Subject: [edk2-announce] TianoCore Community Design Meeting Minutes 
> > - Feb 21, 2020
> >
> > OPEN:
> >   Today's meeting is using Zoom because of the long latency using BlueJeans.
> >   The URL to join meeting is changed. Make sure to check 
> > https://edk2.groups.io/g/devel/calendar   for details.
> >   We will try Zoom for next meeting as well. If everything is good, we will 
> > continue to use Zoom.
> >
> > 1. Platform Libraries for Supporting UEFI Variable Resiliency (HPE)
> > Presenter: Sunny Wang
> > Slides:
> > INVALID URI REMOVED
> > devel_files_Designs_2020_0221_Platform-2520Libraries-2520for-2520Sup
> > po 
> > rting-2520UEFI-2520Variable-25&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z
> > 9c 
> > LgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=U5okqrn3H585vxU4GwALnIBwi
> > 0s 0dQ0hYIDuFj2z-4Y&s=oG0quXKBZu3XD7Drm04CsF445C8kfOGOJGzeqACJxAA&e=
> > 20Resiliency.pdf
> >
> > Problem: Support UEFI variable resiliency to compliant to security 
> > related guidelines and requirements. #page 2
> >
> > Locking BootOrder causes issues in OSes which is not acceptable.
> > EDKII is lack of interfaces for adding platform variable protection.
> > Today's presentation is to propose a solution.
> > Basic rule of how variable resiliency manages BootOrder changes: 
> > #5-#6
> > - Put down untrusted changes
> > - Keep trusted changes
> >
> > @Mike: Where is the reference data stored?
> > @Sunny: In BMC.
> >
> > 
> > @Mike: Would like to see a small enhancement in variable policy protocol 
> > proposed by Microsoft to meet your case.
> > @Sunny: I checked the variable policy proposal by Microsoft. Using that 
> > might be complicated.
> > @Sean: We (Microsoft) have looked this. Variable hook in DXE phase 
> > not in SMM is a security hole. Don't like the way of managing 
> > BootOrder by allowing OS to change BootOrder and reverting. Boot 
> > may contain critical data for OS and reverting that may cause
> troubles.
> > @Sunny: I cannot think of solutions for OS runtime change.
> >
> > 
> > @Mike: I would break the big problem to 3 smaller ones:
> >1. variable data corruption
> > It requires a way to detect corruption and recovery.
> >2. critical platform variables
> > It usually requires a 

Re: [edk2-devel] [PATCH] UnitTestFrameworkPkg: Suspicious check for pointer Suite

[Zhang, Shenglei]

Reviewed-by: Shenglei Zhang  

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> GuoMinJ
> Sent: Wednesday, February 19, 2020 10:35 AM
> To: devel@edk2.groups.io
> Cc: GuoMinJ 
> Subject: [edk2-devel] [PATCH] UnitTestFrameworkPkg: Suspicious check for
> pointer Suite
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2530
> 
> The Suite pointer is used before check if it is valid,
> correct it to check the validation before use.
> 
> Signed-off-by: GuoMinJ 
> ---
>  UnitTestFrameworkPkg/Library/UnitTestLib/RunTests.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/UnitTestFrameworkPkg/Library/UnitTestLib/RunTests.c
> b/UnitTestFrameworkPkg/Library/UnitTestLib/RunTests.c
> index fb247c59e7..b053e04959 100644
> --- a/UnitTestFrameworkPkg/Library/UnitTestLib/RunTests.c
> +++ b/UnitTestFrameworkPkg/Library/UnitTestLib/RunTests.c
> @@ -33,13 +33,13 @@ RunTestSuite (
>UNIT_TEST *Test;
>UNIT_TEST_FRAMEWORK   *ParentFramework;
> 
> -  TestEntry   = NULL;
> -  ParentFramework = (UNIT_TEST_FRAMEWORK *)Suite->ParentFramework;
> -
>if (Suite == NULL) {
>  return EFI_INVALID_PARAMETER;
>}
> 
> +  TestEntry   = NULL;
> +  ParentFramework = (UNIT_TEST_FRAMEWORK *)Suite-
> >ParentFramework;
> +
>DEBUG ((DEBUG_VERBOSE, 
> "
> -\n"));
>DEBUG ((DEBUG_VERBOSE, "RUNNING TEST SUITE: %a\n", Suite->Title));
>DEBUG ((DEBUG_VERBOSE, 
> "
> -\n"));
> --
> 2.17.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55368): https://edk2.groups.io/g/devel/message/55368
Mute This Topic: https://groups.io/mt/71387157/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-