Date   

[PATCH 1/2] Ovmfpkg: update Ia32 build to use new work area

Brijesh Singh
 

The commit 80e67af9afca added support for the generic work area concept
used mainly by the encrypted VMs. In the past, the work area was
preliminary used by the SEV-ES VMs. The SEV-ES support is available for
the X64 builds only. But now, that work area header contains fields that
nonencrypted VMs and SEV VMs can use. They can be built for IA32. So,
moving the work area defines outside of X64.

Fixes: 80e67af9afca ("OvmfPkg: introduce a common work area")
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
OvmfPkg/OvmfPkgIa32X64.fdf | 3 +++
OvmfPkg/ResetVector/ResetVector.nasmb | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 245ca94044df..9d8695922f97 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -76,6 +76,9 @@ [FD.MEMFD]
0x007000|0x001000
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize

+0x008000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize
+
0x010000|0x010000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize

diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/ResetVector.nasmb
index d1d800c56745..21b5fd82b830 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -47,6 +47,8 @@
%include "Ia32/SearchForBfvBase.asm"
%include "Ia32/SearchForSecEntry.asm"

+%define WORK_AREA_GUEST_TYPE (FixedPcdGet32 (PcdOvmfWorkAreaBase))
+
%ifdef ARCH_X64
#include <AutoGen.h>

@@ -72,7 +74,6 @@
%define GHCB_PT_ADDR (FixedPcdGet32 (PcdOvmfSecGhcbPageTableBase))
%define GHCB_BASE (FixedPcdGet32 (PcdOvmfSecGhcbBase))
%define GHCB_SIZE (FixedPcdGet32 (PcdOvmfSecGhcbSize))
- %define WORK_AREA_GUEST_TYPE (FixedPcdGet32 (PcdOvmfWorkAreaBase))
%define SEV_ES_WORK_AREA (FixedPcdGet32 (PcdSevEsWorkAreaBase))
%define SEV_ES_WORK_AREA_RDRAND (FixedPcdGet32 (PcdSevEsWorkAreaBase) + 8)
%define SEV_ES_WORK_AREA_ENC_MASK (FixedPcdGet32 (PcdSevEsWorkAreaBase) + 16)
--
2.25.1


[PATCH 0/2] work area fixes

Brijesh Singh
 

We missed updating the AmdSev package and Ia32 buid to use new work area.

Brijesh Singh (2):
Ovmfpkg: update Ia32 build to use new work area
OvmfPkg/AmdSev: update the fdf to use new workarea PCD

OvmfPkg/AmdSev/AmdSevX64.fdf | 9 ++++++++-
OvmfPkg/OvmfPkgIa32X64.fdf | 3 +++
OvmfPkg/ResetVector/ResetVector.nasmb | 3 ++-
3 files changed, 13 insertions(+), 2 deletions(-)

--
2.25.1


Re: [edk2-platforms][PATCH 05/15] Platform/ARM: Use PcdPciIoTranslation PCD from MdePkg

PierreGondois
 

Hi Abner,

This patch:
https://edk2.groups.io/g/devel/message/81310

renames:
gArmTokenSpaceGuid.PcdPciMmio32Translation

to:
gEfiMdePkgTokenSpaceGuid.PcdPciMmio32Translation

but gArmTokenSpaceGuid.PcdPciMmio32Translation is still used in ARM
platforms,

e.g.: SgiPkg/SgiPlatform.dsc.inc:155: 
gArmTokenSpaceGuid.PcdPciMmio32Translation|0x0

The RdN2 platform which uses this .dsc.inc file can be built with:

build -a AARCH64 -t GCC5 -p Platform/ARM/SgiPkg/RdN2/RdN2.dsc

Regards,

Pierre

On 10/4/21 10:29, Abner Chang via groups.io wrote:
Complaint with BZ: #3665
https://bugzilla.tianocore.org/show_bug.cgi?id=3665

PcdPciIoTranslation PCD is relocated to MdePkg that leveraged by
both ARM and RISC-V arch. This patch uses the one from MdePkg
instead the one under ArmVirtPkg.

Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Thomas Abraham <thomas.abraham@arm.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
---
Platform/ARM/SgiPkg/SgiPlatform.dsc.inc | 3 ++-
Platform/ARM/JunoPkg/ArmJuno.dsc | 3 ++-
.../Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
index 7e37732fb9..6679939d3b 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
@@ -1,5 +1,6 @@
#
# Copyright (c) 2018-2021, ARM Limited. All rights reserved.
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -150,7 +151,7 @@
gArmTokenSpaceGuid.PcdPciBusMax|255
gArmTokenSpaceGuid.PcdPciIoBase|0x0
gArmTokenSpaceGuid.PcdPciIoSize|0x00800000
- gArmTokenSpaceGuid.PcdPciIoTranslation|0x77800000
+ gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0x77800000
gArmTokenSpaceGuid.PcdPciMmio32Translation|0x0
gArmTokenSpaceGuid.PcdPciMmio64Translation|0x0
gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24
diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index fdfc8cd9e2..3b7a63b643 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -1,5 +1,6 @@
#
# Copyright (c) 2013-2018, ARM Limited. All rights reserved.
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -178,7 +179,7 @@
gArmTokenSpaceGuid.PcdPciMmio64Size|0x100000000

gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x40000000
- gArmTokenSpaceGuid.PcdPciIoTranslation|0x5f800000
+ gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0x5f800000
gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24

# List of Device Paths that support BootMonFs
diff --git a/Platform/ARM/JunoPkg/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf b/Platform/ARM/JunoPkg/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf
index 8b4a6e2fad..fb513d7b3d 100644
--- a/Platform/ARM/JunoPkg/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf
+++ b/Platform/ARM/JunoPkg/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf
@@ -2,6 +2,7 @@
# PCI Host Bridge Library instance for ARM Juno
#
# Copyright (c) 2017, Linaro Ltd. All rights reserved.<BR>
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -51,7 +52,7 @@
gArmTokenSpaceGuid.PcdPciBusMax
gArmTokenSpaceGuid.PcdPciIoBase
gArmTokenSpaceGuid.PcdPciIoSize
- gArmTokenSpaceGuid.PcdPciIoTranslation
+ gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation
gArmTokenSpaceGuid.PcdPciMmio32Base
gArmTokenSpaceGuid.PcdPciMmio32Size
gArmTokenSpaceGuid.PcdPciMmio32Translation


Re: [PATCH v2 1/1] SecurityPkg/Library: Add Tpm2NvUndefineSpaceSpecial to Tpm2CommandLib

Bret Barkelew
 

It looks like all errors are still related to ECC and PatchCheck, even though I'm just matching the rest of the file.

Please advise if we want to update the entire file.

On Thu, Oct 14, 2021 at 3:48 AM Yao, Jiewen <jiewen.yao@...> wrote:
Hi Bret
I saw PR failure - https://github.com/tianocore/edk2/pull/2066

Thank you

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Bret
> Barkelew
> Sent: Thursday, October 14, 2021 1:33 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J <jian.j.wang@...>;
> Zhang, Qi1 <qi1.zhang@...>; Kumar, Rahul1 <rahul1.kumar@...>
> Subject: [edk2-devel] [PATCH v2 1/1] SecurityPkg/Library: Add
> Tpm2NvUndefineSpaceSpecial to Tpm2CommandLib
>
> Used to provision and maintain certain HW-defined NV spaces.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2994
>
> Signed-off-by: Bret Barkelew <bret.barkelew@...>
> Reviewed-by: Jiewen Yao <jiewen.yao@...>
> Cc: Jiewen Yao <jiewen.yao@...>
> Cc: Jian J Wang <jian.j.wang@...>
> Cc: Qi Zhang <qi1.zhang@...>
> Cc: Rahul Kumar <rahul1.kumar@...>
> ---
>  SecurityPkg/Library/Tpm2CommandLib/Tpm2NVStorage.c | 122
> ++++++++++++++++++++
>  SecurityPkg/Include/Library/Tpm2CommandLib.h       |  22 ++++
>  2 files changed, 144 insertions(+)
>
> diff --git a/SecurityPkg/Library/Tpm2CommandLib/Tpm2NVStorage.c
> b/SecurityPkg/Library/Tpm2CommandLib/Tpm2NVStorage.c
> index 87572de20164..275cb1683f51 100644
> --- a/SecurityPkg/Library/Tpm2CommandLib/Tpm2NVStorage.c
> +++ b/SecurityPkg/Library/Tpm2CommandLib/Tpm2NVStorage.c
> @@ -24,6 +24,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #define RC_NV_UndefineSpace_authHandle      (TPM_RC_H + TPM_RC_1)
>
>  #define RC_NV_UndefineSpace_nvIndex         (TPM_RC_H + TPM_RC_2)
>
>
>
> +#define RC_NV_UndefineSpaceSpecial_nvIndex  (TPM_RC_H + TPM_RC_1)
>
> +
>
>  #define RC_NV_Read_authHandle               (TPM_RC_H + TPM_RC_1)
>
>  #define RC_NV_Read_nvIndex                  (TPM_RC_H + TPM_RC_2)
>
>  #define RC_NV_Read_size                     (TPM_RC_P + TPM_RC_1)
>
> @@ -74,6 +76,20 @@ typedef struct {
>    TPMS_AUTH_RESPONSE         AuthSession;
>
>  } TPM2_NV_UNDEFINESPACE_RESPONSE;
>
>
>
> +typedef struct {
>
> +  TPM2_COMMAND_HEADER       Header;
>
> +  TPMI_RH_NV_INDEX          NvIndex;
>
> +  TPMI_RH_PLATFORM          Platform;
>
> +  UINT32                    AuthSessionSize;
>
> +  TPMS_AUTH_COMMAND         AuthSession;
>
> +} TPM2_NV_UNDEFINESPACESPECIAL_COMMAND;
>
> +
>
> +typedef struct {
>
> +  TPM2_RESPONSE_HEADER       Header;
>
> +  UINT32                     AuthSessionSize;
>
> +  TPMS_AUTH_RESPONSE         AuthSession;
>
> +} TPM2_NV_UNDEFINESPACESPECIAL_RESPONSE;
>
> +
>
>  typedef struct {
>
>    TPM2_COMMAND_HEADER       Header;
>
>    TPMI_RH_NV_AUTH           AuthHandle;
>
> @@ -506,6 +522,112 @@ Done:
>    return Status;
>
>  }
>
>
>
> +/**
>
> +  This command allows removal of a platform-created NV Index that has
> TPMA_NV_POLICY_DELETE SET.
>
> +
>
> +  @param[in]  NvIndex             The NV Index.
>
> +  @param[in]  IndexAuthSession    Auth session context for the Index
> auth/policy
>
> +  @param[in]  PlatAuthSession     Auth session context for the Platform
> auth/policy
>
> +
>
> +  @retval EFI_SUCCESS             Operation completed successfully.
>
> +  @retval EFI_NOT_FOUND           The command was returned successfully, but
> NvIndex is not found.
>
> +  @retval EFI_UNSUPPORTED         Selected NvIndex does not support deletion
> through this call.
>
> +  @retval EFI_SECURITY_VIOLATION  Deletion is not authorized by current
> policy session.
>
> +  @retval EFI_INVALID_PARAMETER   The command was unsuccessful.
>
> +  @retval EFI_DEVICE_ERROR        The command was unsuccessful.
>
> +**/
>
> +EFI_STATUS
>
> +EFIAPI
>
> +Tpm2NvUndefineSpaceSpecial (
>
> +  IN      TPMI_RH_NV_INDEX          NvIndex,
>
> +  IN      TPMS_AUTH_COMMAND         *IndexAuthSession OPTIONAL,
>
> +  IN      TPMS_AUTH_COMMAND         *PlatAuthSession OPTIONAL
>
> +  )
>
> +{
>
> +  EFI_STATUS                              Status;
>
> +  TPM2_NV_UNDEFINESPACESPECIAL_COMMAND    SendBuffer;
>
> +  TPM2_NV_UNDEFINESPACESPECIAL_RESPONSE   RecvBuffer;
>
> +  UINT32                                  SendBufferSize;
>
> +  UINT32                                  RecvBufferSize;
>
> +  UINT8                                   *Buffer;
>
> +  UINT32                                  IndexAuthSize, PlatAuthSize;
>
> +  TPM_RC                                  ResponseCode;
>
> +
>
> +  //
>
> +  // Construct command
>
> +  //
>
> +  SendBuffer.Header.tag = SwapBytes16(TPM_ST_SESSIONS);
>
> +  SendBuffer.Header.commandCode =
> SwapBytes32(TPM_CC_NV_UndefineSpaceSpecial);
>
> +
>
> +  SendBuffer.NvIndex = SwapBytes32 (NvIndex);
>
> +  SendBuffer.Platform = SwapBytes32 (TPM_RH_PLATFORM);
>
> +
>
> +  //
>
> +  // Marshall the Auth Sessions for the two handles.
>
> +  Buffer = (UINT8 *)&SendBuffer.AuthSession;
>
> +  // IndexAuthSession
>
> +  IndexAuthSize = CopyAuthSessionCommand (IndexAuthSession, Buffer);
>
> +  Buffer += IndexAuthSize;
>
> +  // PlatAuthSession
>
> +  PlatAuthSize = CopyAuthSessionCommand (PlatAuthSession, Buffer);
>
> +  Buffer += PlatAuthSize;
>
> +  // AuthSessionSize
>
> +  SendBuffer.AuthSessionSize = SwapBytes32(IndexAuthSize + PlatAuthSize);
>
> +
>
> +  // Update total command size.
>
> +  SendBufferSize = (UINT32)(Buffer - (UINT8 *)&SendBuffer);
>
> +  SendBuffer.Header.paramSize = SwapBytes32 (SendBufferSize);
>
> +
>
> +  //
>
> +  // send Tpm command
>
> +  //
>
> +  RecvBufferSize = sizeof (RecvBuffer);
>
> +  Status = Tpm2SubmitCommand (SendBufferSize, (UINT8 *)&SendBuffer,
> &RecvBufferSize, (UINT8 *)&RecvBuffer);
>
> +  if (EFI_ERROR (Status)) {
>
> +    goto Done;
>
> +  }
>
> +
>
> +  if (RecvBufferSize < sizeof (TPM2_RESPONSE_HEADER)) {
>
> +    DEBUG ((EFI_D_ERROR, "Tpm2NvUndefineSpaceSpecial - RecvBufferSize
> Error - %x\n", RecvBufferSize));
>
> +    Status = EFI_DEVICE_ERROR;
>
> +    goto Done;
>
> +  }
>
> +
>
> +  ResponseCode = SwapBytes32(RecvBuffer.Header.responseCode);
>
> +  if (ResponseCode != TPM_RC_SUCCESS) {
>
> +    DEBUG ((EFI_D_ERROR, "Tpm2NvUndefineSpaceSpecial - responseCode -
>  %x\n", SwapBytes32(RecvBuffer.Header.responseCode)));
>
> +  }
>
> +  switch (ResponseCode) {
>
> +  case TPM_RC_SUCCESS:
>
> +    // return data
>
> +    break;
>
> +  case TPM_RC_ATTRIBUTES:
>
> +  case TPM_RC_ATTRIBUTES + RC_NV_UndefineSpaceSpecial_nvIndex:
>
> +    Status = EFI_UNSUPPORTED;
>
> +    break;
>
> +  case TPM_RC_NV_AUTHORIZATION:
>
> +    Status = EFI_SECURITY_VIOLATION;
>
> +    break;
>
> +  case TPM_RC_HANDLE + RC_NV_UndefineSpaceSpecial_nvIndex: //
> TPM_RC_NV_DEFINED:
>
> +    Status = EFI_NOT_FOUND;
>
> +    break;
>
> +  case TPM_RC_VALUE + RC_NV_UndefineSpace_nvIndex:
>
> +    Status = EFI_INVALID_PARAMETER;
>
> +    break;
>
> +  default:
>
> +    Status = EFI_DEVICE_ERROR;
>
> +    break;
>
> +  }
>
> +
>
> +Done:
>
> +  //
>
> +  // Clear AuthSession Content
>
> +  //
>
> +  ZeroMem (&SendBuffer, sizeof(SendBuffer));
>
> +  ZeroMem (&RecvBuffer, sizeof(RecvBuffer));
>
> +  return Status;
>
> +}
>
> +
>
>  /**
>
>    This command reads a value from an area in NV memory previously defined by
> TPM2_NV_DefineSpace().
>
>
>
> diff --git a/SecurityPkg/Include/Library/Tpm2CommandLib.h
> b/SecurityPkg/Include/Library/Tpm2CommandLib.h
> index ee8eb622951c..92967662ce96 100644
> --- a/SecurityPkg/Include/Library/Tpm2CommandLib.h
> +++ b/SecurityPkg/Include/Library/Tpm2CommandLib.h
> @@ -364,6 +364,28 @@ Tpm2NvUndefineSpace (
>    IN      TPMS_AUTH_COMMAND         *AuthSession OPTIONAL
>
>    );
>
>
>
> +/**
>
> +  This command allows removal of a platform-created NV Index that has
> TPMA_NV_POLICY_DELETE SET.
>
> +
>
> +  @param[in]  NvIndex             The NV Index.
>
> +  @param[in]  IndexAuthSession    Auth session context for the Index
> auth/policy
>
> +  @param[in]  PlatAuthSession     Auth session context for the Platform
> auth/policy
>
> +
>
> +  @retval EFI_SUCCESS             Operation completed successfully.
>
> +  @retval EFI_NOT_FOUND           The command was returned successfully, but
> NvIndex is not found.
>
> +  @retval EFI_UNSUPPORTED         Selected NvIndex does not support deletion
> through this call.
>
> +  @retval EFI_SECURITY_VIOLATION  Deletion is not authorized by current
> policy session.
>
> +  @retval EFI_INVALID_PARAMETER   The command was unsuccessful.
>
> +  @retval EFI_DEVICE_ERROR        The command was unsuccessful.
>
> +**/
>
> +EFI_STATUS
>
> +EFIAPI
>
> +Tpm2NvUndefineSpaceSpecial (
>
> +  IN      TPMI_RH_NV_INDEX          NvIndex,
>
> +  IN      TPMS_AUTH_COMMAND         *IndexAuthSession OPTIONAL,
>
> +  IN      TPMS_AUTH_COMMAND         *PlatAuthSession OPTIONAL
>
> +  );
>
> +
>
>  /**
>
>    This command reads a value from an area in NV memory previously defined by
> TPM2_NV_DefineSpace().
>
>
>
> --
> 2.31.1.windows.1
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#81922): https://edk2.groups.io/g/devel/message/81922
> Mute This Topic: https://groups.io/mt/86293842/1772286
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [jiewen.yao@...]
> -=-=-=-=-=-=
>


Re: [PATCH V2 0/3] Introduce TdProtocol into EDK2

Yao, Jiewen
 

Hi Sami
To clarify my description:
I am OK to define it in an architecture neutral protocol, such as EFI_TEE_MEASUREMENT_PROTOCOL, or EFI_CCAM_PROTOCOL. I am happy to do that.

However, at current point of time, I am not sure how other arch supports those feature, such as
AMD SEV (https://www.amd.com/system/files/TechDocs/56860.pdf), or ARM Realm (https://developer.arm.com/documentation/ddi0615/latest/). I did not find runtime measurement there.

I hope SEV/Realm people to propose what interface change is required. I am happy to discuss the solution here.

Thank you
Yao Jiewen

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
Sent: Thursday, October 14, 2021 7:59 PM
To: Xu, Min M <min.m.xu@intel.com>; Sami Mujawar
<Sami.Mujawar@arm.com>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Liming Gao
<gaoliming@byosoft.com.cn>; Liu, Zhiguang <zhiguang.liu@intel.com>; Wang,
Jian J <jian.j.wang@intel.com>; Lu, Ken <ken.lu@intel.com>; nd <nd@arm.com>
Subject: Re: [edk2-devel] [PATCH V2 0/3] Introduce TdProtocol into EDK2

Hi Sami
I am not sure if I can understand your comment -
"Some interfaces may need to use an architecture specific library, and some
configuration options would need to be defined using PCDs."

Would you please be more specific?

Thank you
Yao Jiewen


-----Original Message-----
From: Xu, Min M <min.m.xu@intel.com>
Sent: Thursday, October 14, 2021 1:41 PM
To: Sami Mujawar <Sami.Mujawar@arm.com>; devel@edk2.groups.io; Yao,
Jiewen <jiewen.yao@intel.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Liming Gao
<gaoliming@byosoft.com.cn>; Liu, Zhiguang <zhiguang.liu@intel.com>; Wang,
Jian J <jian.j.wang@intel.com>; Lu, Ken <ken.lu@intel.com>; nd
<nd@arm.com>
Subject: RE: [edk2-devel] [PATCH V2 0/3] Introduce TdProtocol into EDK2

On October 12, 2021 11:27 PM, Sami Mujawar wrote:
Hi Min,

Thank you for this patch.

I think it would greatly help if the EFI_TD_PROTOCOL is changed to
something
more architecture neutral. As I understand, this patch series is removing the
dependency on TPM for measurement and is instead providing a lightweight
interface for extending measurements for Confidential Compute
Architecture
(CCA) guests.

Considering this, it would be good to generalise EFI_TD_PROTOCOL as a
Confidential Compute Architecture Measurement (CCAM) protocol.
In fact, your v2 series demonstrates this need with the introduction of
MEASURE_BOOT_PROTOCOLS in "[PATCH V2 2/3] SecurityPkg: Support
TdProtocol in DxeTpm2MeasureBootLib
[https://edk2.groups.io/g/devel/message/81651]".

As it stands, I feel most of the code can be reused/common. Some
interfaces
may need to use an architecture specific library, and some configuration
options would need to be defined using PCDs.

Kindly let me know your thoughts.
Thanks for your comments. Let me first discuss your feedback with our
architecture. We will reply to your proposal a bit later.

Thanks.
Min



Re: [PATCH v1 1/1] StandaloneMmPkg: To support CLANGPDB build

Steven Shi
 

-----Original Message-----
From: Marvin Häuser <mhaeuser@posteo.de>
Sent: Thursday, October 14, 2021 5:08 PM
To: Shi, Steven <steven.shi@intel.com>; devel@edk2.groups.io; Yang,
JiyangX <jiyangx.yang@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Sami Mujawar
<sami.mujawar@arm.com>; Yao, Jiewen <jiewen.yao@intel.com>; Supreeth
Venkatesh <supreeth.venkatesh@arm.com>; Vitaly Cheptsov
<vit9696@protonmail.com>
Subject: Re: [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg: To support
CLANGPDB build

Hey Steven,

As I said, I prefer my patch, but this would work too of course.
I talked about the PIE stuff with Ard before, so maybe he has an opinion
on this? :)

(Small correction for my last e-mail, of course we are not *guaranteed*
there are *no* relocations in .text, but they'd all point to GOT (or
whatever else the target uses for PIE), and references will probably be
relative; for ARM architectures I remember Ard talking about specific
kinds of relocations being avoided entirely).

Best regards,
Marvin

On 14.10.21 11:02, Shi, Steven wrote:

Hi Marvin,

How about we limit the -fno-pie option only apply on IA32 and X64 like
below?

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf
b/StandaloneMmPkg/Core/StandaloneMmCore.inf

[BuildOptions]

   GCC:*_*_*_CC_FLAGS = -fpie

   GCC:*_*_*_DLINK_FLAGS = -Wl,-z,text,-Bsymbolic,-pie

+  CLANGPDB:*_*_ *IA32*_CC_FLAGS= -fno-pie

+  CLANGPDB:*_*_ *X64*_CC_FLAGS= -fno-pie

diff --git
a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm
CoreEntryPoint.inf
b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm
CoreEntryPoint.inf

[BuildOptions]

   GCC:*_*_*_CC_FLAGS = -fpie

+  CLANGPDB:*_*_ *IA32*_CC_FLAGS= -fno-pie

+  CLANGPDB:*_*_ *X64*_CC_FLAGS= -fno-pie

Thanks

Steven Shi

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Marvin

Häuser
Sent: Thursday, October 14, 2021 4:05 PM
To: Yang, JiyangX <jiyangx.yang@intel.com>; devel@edk2.groups.io
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Sami Mujawar
<sami.mujawar@arm.com>; Yao, Jiewen <jiewen.yao@intel.com>;
Supreeth

Venkatesh <supreeth.venkatesh@arm.com>; Vitaly Cheptsov
<vit9696@protonmail.com>; Shi, Steven <steven.shi@intel.com>
Subject: Re: [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg: To support
CLANGPDB build
Hey Jiyang,
NO! Please do not. :)
Yes, this fixes build, but the AARCH64 core (I did not check ARM)
depends on self-relocation as it is loaded in-place at a location
unknown at compile-time. PIE helps ensure there are no relocations in
.text among other things. I know CLANGPDB does not support
ARM/AARCH64
yet, but if it is added, this may generate binaries with more dangerous
relocations, which means the chance of executing an instruction that
requires relocation without relocating first (relocation is done in C
code now!) is significantly higher. We do not need PIE for IA32 or X64
at all (or more specifically, we only need it for ARM-based
architectures as of now), so I prefer my patch which makes that
explicit. Though we can theoretically use your solution when limited to
non-ARM architectures if you really dislike my patch that much.
I'd prefer to hear from the ARM core maintainers before making any
move.

Best regards,
Marvin
On 14.10.21 05:12, Jiyang Yang wrote:
the flag "-fpie" is passed for all builds with a GCC family toolchain,
including CLANGPDB, but CLANGPDB does not support this flag, it will
report "clang: error: unsupported option '-fpie' for target
'x86_64-unknown-windows-gnu'". So we add the CLANGPDB option "-
fno-

pie"
later to overwrite it.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org
<mailto:ardb+tianocore@kernel.org>>

Cc: Sami Mujawar <sami.mujawar@arm.com
<mailto:sami.mujawar@arm.com>>

Cc: Jiewen Yao <jiewen.yao@intel.com <mailto:jiewen.yao@intel.com>>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com
<mailto:supreeth.venkatesh@arm.com>>

Cc: Vitaly Cheptsov <vit9696@protonmail.com
<mailto:vit9696@protonmail.com>>

Cc: Marvin Häuser <mhaeuser@posteo.de
<mailto:mhaeuser@posteo.de>>

Cc: Steven Shi <steven.shi@intel.com <mailto:steven.shi@intel.com>>
Signed-off-by: Jiyang Yang <jiyangx.yang@intel.com
<mailto:jiyangx.yang@intel.com>>

---
StandaloneMmPkg/Core/StandaloneMmCore.inf | 2
++
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmC

oreEntryPoint.inf | 1 +
   2 files changed, 3 insertions(+)
diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf
b/StandaloneMmPkg/Core/StandaloneMmCore.inf
index 56042b7b39f4..3213142523f4 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
@@ -79,3 +79,5 @@
   [BuildOptions]
     GCC:*_*_*_CC_FLAGS = -fpie
     GCC:*_*_*_DLINK_FLAGS = -Wl,-z,text,-Bsymbolic,-pie
+  CLANGPDB:*_*_*_CC_FLAGS = -fno-pie
+  CLANGPDB:*_*_*_DLINK_FLAGS =
diff --git
a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm

CoreEntryPoint.inf
b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm

CoreEntryPoint.inf
index 1762586cfa02..ef69e07d2c07 100644
---
a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm

CoreEntryPoint.inf
+++
b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm

CoreEntryPoint.inf
@@ -56,3 +56,4 @@
   [BuildOptions]
     GCC:*_*_*_CC_FLAGS = -fpie
+  CLANGPDB:*_*_*_CC_FLAGS = -fno-pie


[PATCH 5/5] OvmfPkg/Microvm: add README

Gerd Hoffmann
 

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3599
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
---
OvmfPkg/Microvm/README | 50 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
create mode 100644 OvmfPkg/Microvm/README

diff --git a/OvmfPkg/Microvm/README b/OvmfPkg/Microvm/README
new file mode 100644
index 000000000000..82e2bfe03d37
--- /dev/null
+++ b/OvmfPkg/Microvm/README
@@ -0,0 +1,50 @@
+
+This is an *experimental* port of OVMF for the qemu microvm
+machine type.
+
+microvm background info
+-----------------------
+
+microvm is designed for modern, virtio-based workloads. Most legacy
+lpc/isa devices like pit and pic can be turned off. virtio-mmio
+(i.e. '-device virtio-{blk,net,scsi,...}-device') is used for
+storage/network/etc.
+
+Optional pcie support is available and any pcie device supported by
+qemu can be plugged in (including virtio-pci if you prefer that over
+virtio-mmio).
+
+https://qemu.readthedocs.io/en/latest/system/i386/microvm.html
+https://www.kraxel.org/blog/2020/10/qemu-microvm-acpi/
+
+design issues
+-------------
+
+Not fully clear yet how to do hardware detection best. Right now
+using device tree to find virtio-mmio devices and pcie host bridge,
+can reuse existing ArmVirtPkg code that way. Needs patched qemu.
+
+features
+--------
+ [working] serial console
+ [working] direct kernel boot
+ [working] virtio-mmio support
+ [in progress] pcie support
+
+known limitations
+-----------------
+ * rtc=on is required for now.
+ * can't use separate code/vars (actually an microvm limitation,
+ there is no pflash support).
+ * transitional virtio-pci devices do not work. microvm doesn't
+ support ioports on pcie, and ovmf doesn't initialize pcie devices
+ with ioports if there is no address space for them (even though
+ pcie devices are required to be functional without ioports).
+
+usage
+-----
+qemu-system-x86_64 \
+ -nographic \
+ -machine microvm,acpi=on,pit=off,pic=off,rtc=on \
+ -bios /path/to/MICROVM.fd \
+ [ ... more args here ... ]
--
2.31.1


[PATCH 4/5] OvmfPkg/Microvm/virtio: add virtio-mmio support

Gerd Hoffmann
 

Add virtio-mmio support (VirtioMmioDeviceLib and VirtioFdtDxe).

https://bugzilla.tianocore.org/show_bug.cgi?id=3689
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
OvmfPkg/Microvm/MicrovmX64.dsc | 2 ++
OvmfPkg/Microvm/MicrovmX64.fdf | 1 +
2 files changed, 3 insertions(+)

diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 27d2024266c2..85afdca9beba 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -233,6 +233,7 @@ [LibraryClasses.common]
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
PlatformHookLib|MdeModulePkg/Library/BasePlatformHookLibNull/BasePlatformHookLibNull.inf
FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
+ VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf

[LibraryClasses.common.SEC]
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
@@ -743,6 +744,7 @@ [Components]
# device tree
#
EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
+ OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf

#
# SMBIOS Support
diff --git a/OvmfPkg/Microvm/MicrovmX64.fdf b/OvmfPkg/Microvm/MicrovmX64.fdf
index cc8892a459ee..0bf20a702764 100644
--- a/OvmfPkg/Microvm/MicrovmX64.fdf
+++ b/OvmfPkg/Microvm/MicrovmX64.fdf
@@ -278,6 +278,7 @@ [FV.DXEFV]
INF OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf

INF EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
+INF OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf

!if $(TOOL_CHAIN_TAG) != "XCODE5"
INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
--
2.31.1


[PATCH 3/5] OvmfPkg/Microvm/fdt: add empty fdt

Gerd Hoffmann
 

FdtClient is unhappy without a device tree, so add an empty fdt
which we can use in case etc/fdt is not present in fw_cfg.

https://bugzilla.tianocore.org/show_bug.cgi?id=3689
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
OvmfPkg/PlatformPei/Platform.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 3c0cdba67c83..5071389c1fb4 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -16,6 +16,7 @@
//
// The Library classes this module consumes
//
+#include <Library/BaseMemoryLib.h>
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
#include <Library/HobLib.h>
@@ -321,6 +322,18 @@ PciExBarInitialization (
);
}

+static const UINT8 EmptyFdt[] = {
+ 0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x00, 0x48,
+ 0x00, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00, 0x48,
+ 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
+ 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x09,
+};
+
VOID
MicrovmInitialization (
VOID
@@ -335,8 +348,9 @@ MicrovmInitialization (

Status = QemuFwCfgFindFile ("etc/fdt", &FdtItem, &FdtSize);
if (EFI_ERROR (Status)) {
- DEBUG ((DEBUG_INFO, "%a: no etc/fdt found in fw_cfg\n", __FUNCTION__));
- return;
+ DEBUG ((DEBUG_INFO, "%a: no etc/fdt found in fw_cfg, using dummy\n", __FUNCTION__));
+ FdtItem = 0;
+ FdtSize = sizeof(EmptyFdt);
}

FdtPages = EFI_SIZE_TO_PAGES (FdtSize);
@@ -346,8 +360,12 @@ MicrovmInitialization (
return;
}

- QemuFwCfgSelectItem (FdtItem);
- QemuFwCfgReadBytes (FdtSize, NewBase);
+ if (FdtItem) {
+ QemuFwCfgSelectItem (FdtItem);
+ QemuFwCfgReadBytes (FdtSize, NewBase);
+ } else {
+ CopyMem(NewBase, EmptyFdt, FdtSize);
+ }

FdtHobData = BuildGuidHob (&gFdtHobGuid, sizeof (*FdtHobData));
if (FdtHobData == NULL) {
--
2.31.1


[PATCH 1/5] OvmfPkg/Microvm/fdt: add device tree support

Gerd Hoffmann
 

Add fdt parser from EmbeddedPkg (FdtLib and FdtClientDxe) to MicrovmX64.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
OvmfPkg/Microvm/MicrovmX64.dsc | 6 ++++++
OvmfPkg/Microvm/MicrovmX64.fdf | 2 ++
2 files changed, 8 insertions(+)

diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 617f92539518..27d2024266c2 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -232,6 +232,7 @@ [LibraryClasses.common]
VmgExitLib|OvmfPkg/Library/VmgExitLib/VmgExitLib.inf
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
PlatformHookLib|MdeModulePkg/Library/BasePlatformHookLibNull/BasePlatformHookLibNull.inf
+ FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf

[LibraryClasses.common.SEC]
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
@@ -738,6 +739,11 @@ [Components]
#
MdeModulePkg/Universal/SerialDxe/SerialDxe.inf

+ #
+ # device tree
+ #
+ EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
+
#
# SMBIOS Support
#
diff --git a/OvmfPkg/Microvm/MicrovmX64.fdf b/OvmfPkg/Microvm/MicrovmX64.fdf
index 6314014f3de7..cc8892a459ee 100644
--- a/OvmfPkg/Microvm/MicrovmX64.fdf
+++ b/OvmfPkg/Microvm/MicrovmX64.fdf
@@ -277,6 +277,8 @@ [FV.DXEFV]
INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
INF OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf

+INF EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
+
!if $(TOOL_CHAIN_TAG) != "XCODE5"
INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
INF ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
--
2.31.1


[PATCH 2/5] OvmfPkg/Microvm/fdt: load fdt from fw_cfg

Gerd Hoffmann
 

Needed for hardware detection: virtio-mmio devices for now,
later also pcie root bridge.

Depends on patched qemu which actually provides an fdt:
https://gitlab.com/kraxel/qemu/-/commits/sirius/microvm-device-tree

https://bugzilla.tianocore.org/show_bug.cgi?id=3689
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
OvmfPkg/PlatformPei/PlatformPei.inf | 1 +
OvmfPkg/PlatformPei/Platform.c | 40 +++++++++++++++++++++++++++++
2 files changed, 41 insertions(+)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/PlatformPei/PlatformPei.inf
index 67eb7aa7166b..56876184b17a 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -44,6 +44,7 @@ [Packages]

[Guids]
gEfiMemoryTypeInformationGuid
+ gFdtHobGuid

[LibraryClasses]
BaseLib
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index df2d9ad015aa..3c0cdba67c83 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -321,6 +321,45 @@ PciExBarInitialization (
);
}

+VOID
+MicrovmInitialization (
+ VOID
+ )
+{
+ FIRMWARE_CONFIG_ITEM FdtItem;
+ UINTN FdtSize;
+ UINTN FdtPages;
+ EFI_STATUS Status;
+ UINT64 *FdtHobData;
+ VOID *NewBase;
+
+ Status = QemuFwCfgFindFile ("etc/fdt", &FdtItem, &FdtSize);
+ if (EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_INFO, "%a: no etc/fdt found in fw_cfg\n", __FUNCTION__));
+ return;
+ }
+
+ FdtPages = EFI_SIZE_TO_PAGES (FdtSize);
+ NewBase = AllocatePages (FdtPages);
+ if (NewBase == NULL) {
+ DEBUG ((DEBUG_INFO, "%a: AllocatePages failed\n", __FUNCTION__));
+ return;
+ }
+
+ QemuFwCfgSelectItem (FdtItem);
+ QemuFwCfgReadBytes (FdtSize, NewBase);
+
+ FdtHobData = BuildGuidHob (&gFdtHobGuid, sizeof (*FdtHobData));
+ if (FdtHobData == NULL) {
+ DEBUG ((DEBUG_INFO, "%a: BuildGuidHob failed\n", __FUNCTION__));
+ return;
+ }
+
+ DEBUG ((DEBUG_INFO, "%a: fdt at 0x%x (size %d)\n", __FUNCTION__,
+ NewBase, FdtSize));
+ *FdtHobData = (UINTN)NewBase;
+}
+
VOID
MiscInitialization (
VOID
@@ -368,6 +407,7 @@ MiscInitialization (
break;
case 0xffff: /* microvm */
DEBUG ((DEBUG_INFO, "%a: microvm\n", __FUNCTION__));
+ MicrovmInitialization();
PcdStatus = PcdSet16S (PcdOvmfHostBridgePciDevId,
MICROVM_PSEUDO_DEVICE_ID);
ASSERT_RETURN_ERROR (PcdStatus);
--
2.31.1


[PATCH 0/5] [RfC] OvmfPkg/Microvm: second batch of microvm patches

Gerd Hoffmann
 

Adds support for virtio-mmio devices to microvm.

Needs patched qemu, so posting this only for review.
Actual merge should wait until the host side changes
are accepted to qemu.

While being at it also add the README, the
patch somehow disappeared from the first batch.

Gerd Hoffmann (5):
OvmfPkg/Microvm/fdt: add device tree support
OvmfPkg/Microvm/fdt: load fdt from fw_cfg
OvmfPkg/Microvm/fdt: add empty fdt
OvmfPkg/Microvm/virtio: add virtio-mmio support
OvmfPkg/Microvm: add README

OvmfPkg/Microvm/MicrovmX64.dsc | 8 ++++
OvmfPkg/Microvm/MicrovmX64.fdf | 3 ++
OvmfPkg/PlatformPei/PlatformPei.inf | 1 +
OvmfPkg/PlatformPei/Platform.c | 58 +++++++++++++++++++++++++++++
OvmfPkg/Microvm/README | 50 +++++++++++++++++++++++++
5 files changed, 120 insertions(+)
create mode 100644 OvmfPkg/Microvm/README

--
2.31.1


[PATCH 1/1] DynamicTablesPkg: Fix void pointer arithmetic

PierreGondois
 

From: Pierre Gondois <Pierre.Gondois@arm.com>

Building the DynamicTablesPkg with the additional
-Wpointer-arith flag triggers the following error:
"pointer of type ‘void *’ used in arithmetic
[-Werror=pointer-arith]"

Cast the void pointer to fix the error.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
---
.../Common/TableHelperLib/ConfigurationManagerObjectParser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c b/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
index 2337d47e3fb3..0bdbfbb99c33 100644
--- a/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
+++ b/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
@@ -641,7 +641,7 @@ PrintCmObjDesc (
));
}
DEBUG ((DEBUG_ERROR, "\n"));
- Data += Parser[Index].Length;
+ Data = (UINT8*)Data + Parser[Index].Length;
} // for
}

--
2.17.1


Re: [edk2-platforms: PATCH v5 0/9] MinPlatformPkg: Support FSP 2.3 FSP_NON_VOLATILE_STORAGE_HOB2.

Oram, Isaac W
 

Series Reviewed-by: Isaac Oram <isaac.w.oram@intel.com>

-----Original Message-----
From: Chiu, Chasel <chasel.chiu@intel.com>
Sent: Thursday, October 14, 2021 2:16 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel <chasel.chiu@intel.com>; Oram, Isaac W <isaac.w.oram@intel.com>; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Luo, Heng <heng.luo@intel.com>; Jeremy Soller <jeremy@system76.com>; Benjamin Doron <benjamin.doron00@gmail.com>; Chaganty, Rangasai V <rangasai.v.chaganty@intel.com>; Kethi Reddy, Deepika <deepika.kethi.reddy@intel.com>; Esakkithevar, Kathappan <kathappan.esakkithevar@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>; Dong, Eric <eric.dong@intel.com>
Subject: [edk2-platforms: PATCH v5 0/9] MinPlatformPkg: Support FSP 2.3 FSP_NON_VOLATILE_STORAGE_HOB2.

V5:
Fix GCC build failure in LargeVariableWriteLib.c

V4:
. Switched to LargeVariableRead(Write)Lib in SaveMemoryConfig driver
. Fixed tailing white space issue in PeiLib.c/.h
. Updated function descriptions for PeiGetVariable() and PeiGetLargeVariable()
. Added VariableReadLib to CorePeiLib.dsc for all platforms
. Fixed white space issue in GalagoPro3/.../PeiFspMiscUpdUpdateLib.c

V3:
Fix another GCC build failure.

V2:
Fix GCC build failures.

V1:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3678

Implementation should search FSP_NON_VOLATILE_STORAGE_HOB2 firstly and only search FSP_NON_VOLATILE_STORAGE_HOB when former one is not found.

Also added PeiGetLargeVariable () to support the scenarios where the variable data size is bigger than a single variable size limit.

Cc: Isaac Oram <isaac.w.oram@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Heng Luo <heng.luo@intel.com>
Cc: Jeremy Soller <jeremy@system76.com>
Cc: Benjamin Doron <benjamin.doron00@gmail.com>
Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Cc: Deepika Kethi Reddy <deepika.kethi.reddy@intel.com>
Cc: Kathappan Esakkithevar <kathappan.esakkithevar@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>

Chasel Chiu (9):
MinPlatformPkg: Support FSP 2.3 FSP_NON_VOLATILE_STORAGE_HOB2.
CometlakeOpenBoardPkg: Use same variable name for FspNvsHob.
KabylakeOpenBoardPkg/AspireVn7Dash572G:Use same variable name for
FspNvsHob
KabylakeOpenBoardPkg/GalagoPro3: Use same variable name for FspNvsHob.
KabylakeOpenBoardPkg/KabylakeRvp3: Use same variable name for
FspNvsHob.
TigerlakeOpenBoardPkg: Use same variable name for FspNvsHob.
WhiskeylakeOpenBoardPkg: Use same variable name for FspNvsHob.
WhitleyOpenBoardPkg: Support FSP 2.3 FSP_NON_VOLATILE_STORAGE_HOB2.
WhitleySiliconPkg: Use same variable name for FspNvsHob.

Platform/Intel/CometlakeOpenBoardPkg/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 63 ++++++++++++++-------------------------------------------------
Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 24 ++++++++++--------------
Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c | 23 +++++++++--------------
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 25 +++++++++++--------------
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 25 ++++++++++---------------
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c | 23 +++++++++--------------
Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------------
Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/LargeVariableWriteLib.c | 2 +-
Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------
Platform/Intel/MinPlatformPkg/Library/PeiVariableReadLib/PeiVariableReadLib.c | 4 ++--
Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiFspPolicyInitLib/PeiFspPolicyInitLib.c | 21 ++++++++++++++++++---
Platform/Intel/WhiskeylakeOpenBoardPkg/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 63 ++++++++++++---------------------------------------------------
Platform/Intel/WhiskeylakeOpenBoardPkg/UpXtreme/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 63 ++++++++++++---------------------------------------------------
Platform/Intel/WhitleyOpenBoardPkg/Platform/Dxe/S3NvramSave/S3NvramSave.c | 29 +++++++++++++++++++++++------
Silicon/Intel/WhitleySiliconPkg/Library/FspWrapperPlatformLib/FspWrapperPlatformLib.c | 35 +++++++++--------------------------
Platform/Intel/CometlakeOpenBoardPkg/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 5 ++---
Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 7 ++++---
Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf | 2 +-
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 5 ++---
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 5 ++---
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf | 2 +-
Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig.inf | 8 ++++++--
Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc | 1 +
Platform/Intel/MinPlatformPkg/Include/Library/PeiLib.h | 40 +++++++++++++++++++++++++++++++++++-----
Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.inf | 4 +++-
Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec | 1 +
Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiFspPolicyInitLib/PeiFspPolicyInitLib.inf | 1 +
Platform/Intel/WhiskeylakeOpenBoardPkg/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 5 ++---
Platform/Intel/WhiskeylakeOpenBoardPkg/UpXtreme/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 4 ++--
Platform/Intel/WhiskeylakeOpenBoardPkg/UpXtreme/Include/Fdf/FlashMapInclude.fdf | 18 +++++++++---------
Platform/Intel/WhitleyOpenBoardPkg/Platform/Dxe/S3NvramSave/S3NvramSave.inf | 4 +++-
Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc | 1 +
Silicon/Intel/WhitleySiliconPkg/Library/FspWrapperPlatformLib/FspWrapperPlatformLib.inf | 3 ++-
33 files changed, 345 insertions(+), 369 deletions(-)

--
2.28.0.windows.1


Re: [edk2-rfc] [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64

Leif Lindholm
 

On Mon, Oct 11, 2021 at 21:52:13 +0000, Samer El-Haj-Mahmoud wrote:
For the RFC itself, I personally do not have any objection, and
welcome the addition of this protocol to AARCH64, as long as it
utilizes the PSCI services to achieve the OS boot requirements.

It may be worth getting feedback from Sami since he is the EDK2 maintainer for Arm platforms.
Sami, any comments on this set?

In fact ... we could use more help on ArmPkg in general. Would you be
up for becoming an additional Maintainer or Reviewer?

/
Leif


Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64

Rebecca Cran
 

On 9/28/21 5:14 AM, Leif Lindholm wrote:

On Fri, Sep 24, 2021 at 20:17:50 -0600, Rebecca Cran wrote:
I'd like to propose adding EFI_MP_SERVICES_PROTOCOL support for
AARCH64 systems. I've attached two patches to implement support for it
in the DXE phase, based on code in EmulatorPkg and UefiCpuPkg. It's added
under ArmPkg for now, but longer term it should probably be moved into
UefiCpuPkg.

Patch 1/2 is the start of addressing the issue that the Aff0 field of
the MPIDR is no longer guaranteed to be the core, and should be referred
to in a more generic way: for example it could be the thread, with Aff1
being the core and Aff2 the cluster. Clearly much more work is needed
to fully remove that assumption.
Just to add to this:
Aff0 was never defined by the architecture to be the "core", it was
just the smallest schedulable entity. The intent being that whether
you had multiple hardware threads per core or not, you could just use
the affinity to determine whether
There is also a bit in the MPIDR to indicate whether the core *had*
multiple hardware threads.

In recent processors (without any change to the architecture), ARM
thought it would be beneficial to keep software developers on their
toes by starting to use the hyperthreading layout even for processors
without hyperthreading support. I.e. Aff0 is always 0 even though MT
is 0:
https://developer.arm.com/documentation/100798/0301/Register-descriptions/AArch64-system-registers/MPIDR-EL1--Multiprocessor-Affinity-Register--EL1
The justification being that an SoC might contain both processors
with and without multiple hardware threads per core.

Anyway, the point is that from at least Cortex-A76 onwards, Aff0 no
longer maps to CoreId universally, and Aff1 no longer maps to
ClusterId, for all non-threaded implementations.
So we need to start cleaning up this use.
This will possibly break some out-of-tree platforms, but I figure
we're far enough from next stable tag for that not to matter too
much.
This patch will also break out-of-tree platforms because it causes ArmPkg/Drivers/CpuDxe to gain a dependency on MpInitLib.


--
Rebecca Cran


Cancelled Event: TianoCore Design Meeting - APAC/NAMO - Friday, October 15, 2021 #cal-cancelled

devel@edk2.groups.io Calendar <noreply@...>
 

Cancelled: TianoCore Design Meeting - APAC/NAMO

This event has been cancelled.

When:
Friday, October 15, 2021
9:30am to 10:30am
(UTC+08:00) Asia/Shanghai

Where:
Microsoft Teams

Organizer: Ray Ni ray.ni@...

Description:

TOPIC

  1. NA

For more info, see here: https://www.tianocore.org/design-meeting/


Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 119 715 416 0

Alternate VTC dialing instructions

Learn More | Meeting options


Re: [PATCH v1] ArmPkg/Smbios: Fix max cache size 2 wrong issue

Rebecca Cran
 

Reviewed-by: Rebecca Cran <rebecca@nuviainc.com>

On 10/14/21 1:23 AM, Ming Huang wrote:
As SMBIOS spec, bit-31 of maximum cache size 2 should be 1
for 64K granularity.

Signed-off-by: Ming Huang <huangming@linux.alibaba.com>
---
ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c b/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c
index fb484086a4..4b409ff745 100644
--- a/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c
+++ b/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c
@@ -219,7 +219,7 @@ ConfigureCacheArchitectureInformation (
CacheSize32 = CacheSize16;
} else if ((CacheSize64 / 64) < MAX_INT16) {
CacheSize16 = (1 << 15) | (CacheSize64 / 64);
- CacheSize32 = CacheSize16;
+ CacheSize32 = (1 << 31) | (CacheSize64 / 64);
} else {
if ((CacheSize64 / 1024) <= 2047) {
CacheSize32 = CacheSize64;


Re: [PATCH V2 0/3] Introduce TdProtocol into EDK2

Yao, Jiewen
 

Hi Sami
I am not sure if I can understand your comment -
"Some interfaces may need to use an architecture specific library, and some configuration options would need to be defined using PCDs."

Would you please be more specific?

Thank you
Yao Jiewen

-----Original Message-----
From: Xu, Min M <min.m.xu@intel.com>
Sent: Thursday, October 14, 2021 1:41 PM
To: Sami Mujawar <Sami.Mujawar@arm.com>; devel@edk2.groups.io; Yao,
Jiewen <jiewen.yao@intel.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Liming Gao
<gaoliming@byosoft.com.cn>; Liu, Zhiguang <zhiguang.liu@intel.com>; Wang,
Jian J <jian.j.wang@intel.com>; Lu, Ken <ken.lu@intel.com>; nd <nd@arm.com>
Subject: RE: [edk2-devel] [PATCH V2 0/3] Introduce TdProtocol into EDK2

On October 12, 2021 11:27 PM, Sami Mujawar wrote:
Hi Min,

Thank you for this patch.

I think it would greatly help if the EFI_TD_PROTOCOL is changed to something
more architecture neutral. As I understand, this patch series is removing the
dependency on TPM for measurement and is instead providing a lightweight
interface for extending measurements for Confidential Compute Architecture
(CCA) guests.

Considering this, it would be good to generalise EFI_TD_PROTOCOL as a
Confidential Compute Architecture Measurement (CCAM) protocol.
In fact, your v2 series demonstrates this need with the introduction of
MEASURE_BOOT_PROTOCOLS in "[PATCH V2 2/3] SecurityPkg: Support
TdProtocol in DxeTpm2MeasureBootLib
[https://edk2.groups.io/g/devel/message/81651]".

As it stands, I feel most of the code can be reused/common. Some interfaces
may need to use an architecture specific library, and some configuration
options would need to be defined using PCDs.

Kindly let me know your thoughts.
Thanks for your comments. Let me first discuss your feedback with our
architecture. We will reply to your proposal a bit later.

Thanks.
Min


Re: [PATCH V3 00/12] Migrate ArmVirtPkg modules to OvmfPkg

Ard Biesheuvel
 

On Thu, 14 Oct 2021 at 12:14, Chang, Abner (HPS SW/FW Technologist)
<abner.chang@hpe.com> wrote:

Hi Are, I am so sorry about that I just merged it two hours ago. Any process needed if we want to change the commit messages for adding your review tag?
Don't worry about it.


________________________________
From: Ard Biesheuvel <ardb@kernel.org>
Sent: Thursday, October 14, 2021 5:51:56 PM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Cc: gaoliming <gaoliming@byosoft.com.cn>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Leif Lindholm <leif@nuviainc.com>; Sami Mujawar <sami.mujawar@arm.com>; Jiewen Yao <jiewen.yao@intel.com>; Jordan Justen <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.com>; Zhiguang Liu <zhiguang.liu@intel.com>; Michael D Kinney <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH V3 00/12] Migrate ArmVirtPkg modules to OvmfPkg

On Tue, 12 Oct 2021 at 06:17, Abner Chang <abner.chang@hpe.com> wrote:

Hi package maintainers,

The review process of this patch set is almost done and please allow me to merge it because the corresponding changes on edk2-platform is also required to merge.



Ard and Leif, do I need the Reviewed-by or Acked-by from either of you? Or I can just proceed the merge process as Ard has no problem with this patch set?

Hi Abner,

Where needed

Acked-by: Ard Biesheuvel <ardb@kernel.org>

Feel free to merge it whenever convenient for you.



From: gaoliming [mailto:gaoliming@byosoft.com.cn]
Sent: Monday, October 11, 2021 9:22 AM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; ardb@kernel.org
Cc: 'Ard Biesheuvel' <ardb+tianocore@kernel.org>; 'Leif Lindholm' <leif@nuviainc.com>; 'Sami Mujawar' <sami.mujawar@arm.com>; 'Jiewen Yao' <jiewen.yao@intel.com>; 'Jordan Justen' <jordan.l.justen@intel.com>; 'Gerd Hoffmann' <kraxel@redhat.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>; 'Sunil V L' <sunilvl@ventanamicro.com>; 'Zhiguang Liu' <zhiguang.liu@intel.com>; 'Michael D Kinney' <michael.d.kinney@intel.com>
Subject: 回复: [edk2-devel] [PATCH V3 00/12] Migrate ArmVirtPkg modules to OvmfPkg



The change in MdePkg is good to me. Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>



发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Abner Chang
发送时间: 2021年10月8日 11:39
收件人: devel@edk2.groups.io; gaoliming@byosoft.com.cn; ardb@kernel.org
抄送: 'Ard Biesheuvel' <ardb+tianocore@kernel.org>; 'Leif Lindholm' <leif@nuviainc.com>; 'Sami Mujawar' <sami.mujawar@arm.com>; 'Jiewen Yao' <jiewen.yao@intel.com>; 'Jordan Justen' <jordan.l.justen@intel.com>; 'Gerd Hoffmann' <kraxel@redhat.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>; 'Sunil V L' <sunilvl@ventanamicro.com>; 'Zhiguang Liu' <zhiguang.liu@intel.com>; 'Michael D Kinney' <michael.d.kinney@intel.com>
主题: Re: [edk2-devel] [PATCH V3 00/12] Migrate ArmVirtPkg modules to OvmfPkg



Thanks Liming, could you please also give the reviewed-by.



Hi Ard, also need your reviewed-by for ArmPkg. Then this changes could be upstream and finished.

Thanks

Abner





From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of gaoliming
Sent: Friday, October 8, 2021 11:14 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; 'edk2-devel-groups-io' <devel@edk2.groups.io>; ardb@kernel.org
Cc: 'Ard Biesheuvel' <ardb+tianocore@kernel.org>; 'Leif Lindholm' <leif@nuviainc.com>; 'Sami Mujawar' <sami.mujawar@arm.com>; 'Jiewen Yao' <jiewen.yao@intel.com>; 'Jordan Justen' <jordan.l.justen@intel.com>; 'Gerd Hoffmann' <kraxel@redhat.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>; 'Sunil V L' <sunilvl@ventanamicro.com>; 'Zhiguang Liu' <zhiguang.liu@intel.com>; 'Michael D Kinney' <michael.d.kinney@intel.com>
Subject: 回复: [edk2-devel] [PATCH V3 00/12] Migrate ArmVirtPkg modules to OvmfPkg



Ard and Abner:

I am OK to add these three PCDs PcdPciMmio32Translation, PcdPciMmio64Translation, PcdPciIoTranslation to MdePkg.



Thanks

Liming

发件人: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
发送时间: 2021年10月6日 17:27
收件人: edk2-devel-groups-io <devel@edk2.groups.io>; ardb@kernel.org; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
抄送: Ard Biesheuvel <ardb+tianocore@kernel.org>; Leif Lindholm <leif@nuviainc.com>; Sami Mujawar <sami.mujawar@arm.com>; Jiewen Yao <jiewen.yao@intel.com>; Jordan Justen <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.com>; Liming Gao <gaoliming@byosoft.com.cn>; Zhiguang Liu <zhiguang.liu@intel.com>; Michael D Kinney <michael.d.kinney@intel.com>
主题: Re: [edk2-devel] [PATCH V3 00/12] Migrate ArmVirtPkg modules to OvmfPkg



Hi Ard,

I realized there is a problem if we duplicate ArmPkg defined PCD to under OvmfPkg (e.g. PcdPciIoTranslate PCD) when I was duplicating this PCD to OvmfPkg.

FdtPciProducerLib is relocated to OvmfPkg/Fdt and uses PcdPciIoTranslate PCD declared with OvmfPkg namespace. FdtPciProducerLib is also used by both ArmVirtPkg and RiscVVirtPkg.

ArmVirtPkg uses ArmPciCpuIoDxe provided by ArmPkg however PcdPciIoTranslate used by ArmPciCpuIoDxe is declared with ArmPkg namespace.

I think this results in the problem because PcdPciIoTranslate(s) that are referred by ArmPkg and ArmVirtPkg come from two different namespaces, right? Unless ArmPciCpuIoDxe uses the one declared in OvmfPkg, but I don't think we want to do this.

Thought? Otherwise, we should still keep the original patch that relocates these PCDs under MdePkg.



Thanks

Abner





________________________________

From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Abner Chang <abner.chang@hpe.com>
Sent: Tuesday, October 5, 2021 11:00 PM
To: edk2-devel-groups-io <devel@edk2.groups.io>; ardb@kernel.org <ardb@kernel.org>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Leif Lindholm <leif@nuviainc.com>; Sami Mujawar <sami.mujawar@arm.com>; Jiewen Yao <jiewen.yao@intel.com>; Jordan Justen <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.com>; Liming Gao <gaoliming@byosoft.com.cn>; Zhiguang Liu <zhiguang.liu@intel.com>; Michael D Kinney <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH V3 00/12] Migrate ArmVirtPkg modules to OvmfPkg



Hi Ard,

This way reduces the impact of MdePkg. We can try it.



Thanks

Abner



________________________________

From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Ard Biesheuvel <ardb@kernel.org>
Sent: Tuesday, October 5, 2021 5:30 PM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Leif Lindholm <leif@nuviainc.com>; Sami Mujawar <sami.mujawar@arm.com>; Jiewen Yao <jiewen.yao@intel.com>; Jordan Justen <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.com>; Liming Gao <gaoliming@byosoft.com.cn>; Zhiguang Liu <zhiguang.liu@intel.com>; Michael D Kinney <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH V3 00/12] Migrate ArmVirtPkg modules to OvmfPkg



On Thu, 30 Sept 2021 at 03:43, Abner Chang <abner.chang@hpe.com> wrote:

In V3: Address comments on V2.
In V2: Remove HPE license on the files that just moved around or
the changes in the file are just code removal.

edk2 BZ #: 3665
edk2 platform corresponding changes will be submitted after
this pactch set is reviewed.

This pacthes set is to migrate some modules from ArmVirtPkg
to under OvmfPkg for the upcoming RiscVVirtPkg that can leverage
those modules without the dependency with Arm*Pkg.

The modules moved from ArmVirtPkg to OvmfPkg are,
- FdtClientDxe
- PciPcdProducerLib
- HighMemDxe
- QemuFwCfgLib
- FdtPciHostBridgeLib
- VirtioFdtDxe

Below PCDs are moved to under MdePkg and leverage by RiscVVirtPkg.
This change also remove the dependency on ArmPkg of OvmfPkg.
- PcdPciIoTranslation
- PcdPciIoTranslation
- PcdPciMmio32(64)Translation

Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>

Abner Chang (12):
ArmVirtPkg/FdtClintDxe: Move FdtClientDxe to EmbeddedPkg
MdePkg: Add PcdPciIoTranslation PCD
ArmPkg: Use PcdPciIoTranslation PCD from MdePkg
ArmVirtPkg/FdtPciPcdProducerLib: Relocate PciPcdProducerLib to OvmfPkg
ArmVirtPkg/HighMemDxe: Relocate HighMemDxe to OvmfPkg
OvmfPkg/HighMemDxe: Add RISC-V in the supported arch.
ArmVirtPkg/QemuFwCfgLib: Relocate QemuFwCfgLib to OvmfPkg
OvmfPkg/QemuFwCfgLibMMIO: Add RISC-V arch support
MdePkg: Add PcdPciMmio32(64)Translation PCDs
ArmVirtPkg/FdtPciHostBridgeLib: Relocate FdtPciHostBridgeLib to
OvmfPkg/Fdt
OvmfPkg/FdtPciHostBridgeLib: Add RISC-V in the supported arch.
ArmVirtPkg/VirtioFdtDxe: Relocate VirtioFdtDxe to OvmfPkg/Fdt
Hello all,

These patches look ok to me, but I wonder if the MdePkg maintainers
are happy taking these PCD declaration changes. Translations for PCIe
are typically defined per host bridge, and I would rather move away
from using PCDs for this entirely than 'promote' them by carrying them
in MdePkg.

As this issue is somewhat orthogonal to what Abner is trying to fix,
perhaps it is better to avoid MdePkg changes for now, and just
duplicate these PCDs into OvmfPkg. This is reasonable, given that we
know that QEMU only exposes a single host bridge.

The one in ArmPkg can hopefully be removed and replaced with something
that is more appropriate.


ArmPkg/ArmPkg.dec | 15 ++++++--------
ArmVirtPkg/ArmVirtPkg.dec | 3 ---
EmbeddedPkg/EmbeddedPkg.dec | 1 +
MdePkg/MdePkg.dec | 12 +++++++++++
ArmVirtPkg/ArmVirtCloudHv.dsc | 18 ++++++++---------
ArmVirtPkg/ArmVirtKvmTool.dsc | 18 ++++++++---------
ArmVirtPkg/ArmVirtQemu.dsc | 20 +++++++++----------
ArmVirtPkg/ArmVirtQemuKernel.dsc | 20 +++++++++----------
ArmVirtPkg/ArmVirtXen.dsc | 2 +-
EmbeddedPkg/EmbeddedPkg.dsc | 1 +
ArmVirtPkg/ArmVirtCloudHv.fdf | 6 +++---
ArmVirtPkg/ArmVirtKvmTool.fdf | 6 +++---
ArmVirtPkg/ArmVirtXen.fdf | 2 +-
ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 6 +++---
.../ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf | 2 +-
.../ArmVirtGicArchLib/ArmVirtGicArchLib.inf | 1 +
.../ArmVirtPL031FdtClientLib.inf | 1 +
.../ArmVirtPsciResetSystemLib.inf | 1 +
.../ArmVirtTimerFdtClientLib.inf | 1 +
.../KvmtoolRtcFdtClientLib.inf | 1 +
.../NorFlashKvmtoolLib/NorFlashKvmtoolLib.inf | 1 +
.../NorFlashQemuLib/NorFlashQemuLib.inf | 1 +
.../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf | 1 +
ArmVirtPkg/XenioFdtDxe/XenioFdtDxe.inf | 1 +
.../Drivers}/FdtClientDxe/FdtClientDxe.inf | 1 -
.../FdtPciHostBridgeLib.inf | 11 +++++-----
.../FdtPciPcdProducerLib.inf | 5 ++---
.../Fdt}/HighMemDxe/HighMemDxe.inf | 7 ++++---
.../Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf | 2 +-
.../Library/QemuFwCfgLib/QemuFwCfgLibMmio.inf | 6 +++---
.../Include/Protocol/FdtClient.h | 0
.../Drivers}/FdtClientDxe/FdtClientDxe.c | 0
.../FdtPciHostBridgeLib/FdtPciHostBridgeLib.c | 0
.../FdtPciPcdProducerLib.c | 0
.../Fdt}/HighMemDxe/HighMemDxe.c | 3 ++-
.../Fdt}/VirtioFdtDxe/VirtioFdtDxe.c | 0
.../Library/QemuFwCfgLib/QemuFwCfgLibMmio.c | 7 ++++---
Maintainers.txt | 6 ++++++
38 files changed, 106 insertions(+), 83 deletions(-)
rename {ArmVirtPkg => EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.inf (92%)
rename {ArmVirtPkg/Library => OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf (77%)
rename {ArmVirtPkg/Library => OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf (87%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.inf (83%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf (92%)
rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf => OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmio.inf (86%)
rename {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h (100%)
rename {ArmVirtPkg => EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.c (100%)
rename {ArmVirtPkg/Library => OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c (100%)
rename {ArmVirtPkg/Library => OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c (100%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.c (95%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.c (100%)
rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c => OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmio.c (93%)

--
2.17.1





2521 - 2540 of 84490