[edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

2020-08-23 Thread gaoliming 
Hi, all

Based on the discussion https://edk2.groups.io/g/devel/message/64493, we
make the conclusion to defer one week for edk2-stable202008 to include the
important patch for RiscV. Soft Feature Freeze (SFF) will start from today
(2020-08-24). Below is new edk2-stable202008 tag planning proposed schedule

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Plannin
g. If you have any comments, please raise it.

 

Date (00:00:00 UTC-8) Description

2020-06-03  Beginning of development

2020-08-07  Feature Planning Freeze

2020-08-24  Soft Feature Freeze

2020-08-28  Hard Feature Freeze

2020-09-04  Release

 

Because SFF date is changed, if the patches passed code review before SFF
date (2020-08-24), the patches can still be merged for this stable tag. Here
is the patch list those passed code review before new SFF date. For below
features, I will let the feature owner decides whether to merge it for this
stable tag.

 

Feature List:

https://edk2.groups.io/g/devel/message/63767 [PATCH] EmbeddedPkg/libfdt: Add
strncmp macro to use AsciiStrnCmp

https://edk2.groups.io/g/devel/message/64363 [PATCH v5 0/3] UefiPayloadPkg:
Runtime MMCONF

https://edk2.groups.io/g/devel/message/64354 [PATCH v4 0/8] Need add a FSP
binary measurement

 

Bug List:

https://edk2.groups.io/g/devel/message/50406 [PATCH 1/1] MdePkg/Include: Add
missing definitions of SMBIOS type 42h in SmBios.h

https://edk2.groups.io/g/devel/message/64507 [PATCH v2 1/1]
UefiCpuPkg/MpInitLib: Always initialize the DoDecrement variable

https://edk2.groups.io/g/devel/message/64539 [PATCH] Maintainers.txt: Update
Liming mail address

https://edk2.groups.io/g/devel/message/64529 [PATCH] .pytool/EccCheck:
Disable Ecc error code 10014 for open CI

https://edk2.groups.io/g/devel/message/61938 [PATCH v2 1/1] MdePkg :
UefiFileHandleLib: fix buffer overrun in FileHandleReadLine()

 

The remaining patches can continue to review without break in edk2
community. If the patch is sent before Soft Feature Freeze, and plans to
catch this stable tag, the patch contributor need reply to his patch and
notify edk2 community. If the patch is sent after Soft Feature Freeze, and
plans to catch this stable tag, please add edk2-stable202008 key words in
the patch title and BZ, so the community know this patch target and give the
feedback.

 

Thanks

Liming


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

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

[edk2-devel] [patch][edk2-platforms] Maintainers.txt: Update Liming mail address

2020-08-23 Thread gaoliming 
Signed-off-by: Liming Gao 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
---
 Maintainers.txt | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 6ed57dd73b..5132a2483a 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -129,17 +129,17 @@ R: Ard Biesheuvel 
 Features/Intel
 F: Features/Intel/
 M: Sai Chaganty 
-R: Liming Gao 
+R: Liming Gao 
 
 Features/Intel/Debugging
 F: Features/Intel/Debugging/
 M: Eric Dong 
-R: Liming Gao 
+R: Liming Gao 
 
 Features/Intel/UserInterface
 F: Features/Intel/UserInterface/
 M: Dandan Bi 
-R: Liming Gao 
+R: Liming Gao 
 
 Platform/Intel/QuarkPlatformPkg
 F: Platform/Intel/QuarkPlatformPkg/
@@ -154,7 +154,7 @@ M: Yi Qian 
 Platform/Intel/BoardModulePkg
 F: Platform/Intel/BoardModulePkg/
 M: Eric Dong 
-R: Liming Gao 
+R: Liming Gao 
 
 Platform/Intel/KabylakeOpenBoardPkg
 F: Platform/Intel/KabylakeOpenBoardPkg/
@@ -169,7 +169,7 @@ Platform/Intel/MinPlatformPkg
 F: Platform/Intel/MinPlatformPkg/
 M: Chasel Chiu 
 M: Nate DeSimone 
-R: Liming Gao 
+R: Liming Gao 
 R: Eric Dong 
 
 Platform/Intel/WhiskeylakeOpenBoardPkg
@@ -192,7 +192,7 @@ M: Agyeman Prince 
 Platform/Intel/Tools
 F: Platform/Intel/Tools/
 M: Bob Feng 
-M: Liming Gao 
+M: Liming Gao 
 R: Yuwei Chen 
 
 Silicon/Intel/IntelSiliconPkg
@@ -231,7 +231,7 @@ M: Agyeman Prince 
 Silicon/Intel/Tools
 F: Silicon/Intel/Tools/
 M: Bob Feng 
-M: Liming Gao 
+M: Liming Gao 
 R: Yuwei Chen 
 
 Marvell platforms and silicon
-- 
2.27.0.windows.1



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

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

Re: [edk2-devel] intel: EDK2 Build failure for Quark/Gallileo

2020-08-23 Thread Sahaj Sarup 
Canh,

I've tried with both python 3 and 2 across ubuntu 18.04 and fedora 32.

On Sun, Aug 23, 2020, 19:45 Canh Kha  wrote:

> Sahaj,
> Can you can with python 3.7.n or a newer one?
> Thanks,
> Canh Kha
> 
>
>

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

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

[edk2-devel] arm64: AMD Overdrive MNP Bug

2020-08-23 Thread Sahaj Sarup 
Hi all,

I just flashed edk2 to my AMD Overdrive 3000 for the first time, it is
a fresh edk2 build as well.

When it boot i'm bombarded with this error:
MnpReceivePacket: Snp->Receive() = Device Error.

This continues till the OS takes over UART, it makes the edk2 TUI
completely unusable.
Please let me know if you require any other logs and for the time
being is there a way to suppress this message or disable the component
completely?


-- 
Best Regards
Sahaj Sarup

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

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

Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow

2020-08-23 Thread Michael Brown 

On 21/08/2020 12:19, Laszlo Ersek wrote:

On 08/19/20 20:46, Michael Brown wrote:

FWIW, iPXE's equivalent logic (based on a combination of what the PXE
spec says and what the Intel reference PXE implementation actually does,
which is not necessarily the same thing) is to *ignore* PXE_BOOT_SERVERS
if a DHCP filename is available and option 43 tag 6 bit 3 is *set*.


Sorry, I expressed my concern incorrectly (I think I was tripped up by
the typo in Maciej's commit message).


My fault; I should have read more closely.


It's about bit#2 in PXE_DISCOVERY_CONTROL.

The question is whether bit#2 is *equivalent* to adhering to
PXE_BOOT_SERVERS ("if, and only if").

When bit#2 is set, the spec says we must. OK.

When bit#2 is clear, the spec doesn't say anything. So two
interpretations are possible, "we still may consider PXE_BOOT_SERVERS",
and "we must not consider PXE_BOOT_SERVERS".


iPXE's interpretation is:

- if bit 2 is set then the subsequent boot server discovery will ignore 
replies from any servers not mentioned (for the selected boot server 
type) in PXE_BOOT_SERVERS


- if bit 2 is clear then the subsequent boot server discovery will 
accept replies from any server


This seems consistent with the spec paragraph stating:

  "If PXE_DISCOVERY_CONTROL bit 2 is set, the client may still use
   multicast and broadcast discovery (if it is permitted by bits 0
   and 1); but the client may only accept replies from servers that
   are identified in the PXE_BOOT_SERVERS option."


Anyway -- I'm sending this just to explain my earlier email. My main
point remains:

11640b08-6f42-e4d8-356d-91d4bdf86c2c@redhat.com">http://mid.mail-archive.com/11640b08-6f42-e4d8-356d-91d4bdf86c2c@redhat.com

(alt link: https://edk2.groups.io/g/devel/message/64530)


Resolving as INVALID seems appropriate to me.

Thanks,

Michael

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

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

Re: [edk2-devel] intel: EDK2 Build failure for Quark/Gallileo

2020-08-23 Thread Canh Kha 
Sahaj,
Can you can with python 3.7.n or a newer one?
Thanks,
Canh Kha

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

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

Re: [edk2-devel] [PATCH] OvmfPkg/SmmControl2Dxe: negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG

2020-08-23 Thread Ard Biesheuvel 

On 8/21/20 3:53 PM, Laszlo Ersek wrote:

Hi Ard,

can you please ACK this patch?

I'm not (necessarily) aiming at the upcoming stable tag, but Igor has
resumed work on the QEMU-side patches [*], so this is again relevant for
edk2.

[*] http://mid.mail-archive.com/20200818122208.1243901-1-imammedo@redhat.com
https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg03892.html

(Top-posting because I want to keep the full context intact for you.)

Thanks!
Laszlo

On 07/14/20 20:43, Laszlo Ersek wrote:

The ICH9_LPC_SMI_F_BROADCAST and ICH9_LPC_SMI_F_CPU_HOTPLUG feature flags
cause QEMU to behave as follows:

   BROADCAST  CPU_HOTPLUG  use case / behavior
   -  ---  
   clear  clearOVMF built without SMM_REQUIRE; or very old OVMF
   (from before commit a316d7ac91d3 / 2017-02-07).
   QEMU permits CPU hotplug operations, and does
   not cause the OS to inject an SMI upon hotplug.
   Firmware is not expected to be aware of hotplug
   events.

   clear  set  Invalid feature set; QEMU rejects the feature
   negotiation.

   setclearOVMF after a316d7ac91d3 / 2017-02-07, built with
   SMM_REQUIRE, but no support for CPU hotplug.
   QEMU gracefully refuses hotplug operations.

   setset  OVMF after a316d7ac91d3 / 2017-02-07, built with
   SMM_REQUIRE, and supporting CPU hotplug. QEMU
   permits CPU hotplug operations, and causes the
   OS to inject an SMI upon hotplug. Firmware is
   expected to deal with hotplug events.

Negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG -- but only if SEV is disabled, as
OvmfPkg/CpuHotplugSmm can't deal with SEV yet.

Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Igor Mammedov 
Cc: Jordan Justen 
Cc: Liran Alon 
Cc: Philippe Mathieu-Daudé 
Signed-off-by: Laszlo Ersek 


Acked-by: Ard Biesheuvel 


---

Notes:
 This is the OVMF counterpart to Igor's QEMU series:

 - [RFC 0/3] x86: fix cpu hotplug with secure boot
   https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg03746.html
   message-id: <20200710161704.309824-1-imamm...@redhat.com>

 Repo:   https://pagure.io/lersek/edk2.git
 Branch: negotiate_cpuhp_with_smi_rhbz1849177

  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf |  1 +
  OvmfPkg/SmmControl2Dxe/SmiFeatures.c  | 26 ++--
  2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf 
b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
index 3abed141e644..b8fdea8deb84 100644
--- a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+++ b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
@@ -46,6 +46,7 @@ [LibraryClasses]
BaseLib
DebugLib
IoLib
+  MemEncryptSevLib
MemoryAllocationLib
PcdLib
PciLib
diff --git a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c 
b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
index 6210b7515e3e..c9d875543205 100644
--- a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
+++ b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
@@ -9,6 +9,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -21,6 +22,12 @@
  // "etc/smi/supported-features" and "etc/smi/requested-features" fw_cfg files.
  //
  #define ICH9_LPC_SMI_F_BROADCAST BIT0
+//
+// The following bit value stands for "enable CPU hotplug, and inject an SMI
+// with control value ICH9_APM_CNT_CPU_HOTPLUG upon hotplug", in the
+// "etc/smi/supported-features" and "etc/smi/requested-features" fw_cfg files.
+//
+#define ICH9_LPC_SMI_F_CPU_HOTPLUG BIT1
  
  //

  // Provides a scratch buffer (allocated in EfiReservedMemoryType type memory)
@@ -67,6 +74,7 @@ NegotiateSmiFeatures (
UINTNSupportedFeaturesSize;
UINTNRequestedFeaturesSize;
UINTNFeaturesOkSize;
+  UINT64   RequestedFeaturesMask;
  
//

// Look up the fw_cfg files used for feature negotiation. The selector keys
@@ -104,9 +112,16 @@ NegotiateSmiFeatures (
QemuFwCfgReadBytes (sizeof mSmiFeatures, );
  
//

-  // We want broadcast SMI and nothing else.
+  // We want broadcast SMI, SMI on CPU hotplug, and nothing else.
//
-  mSmiFeatures &= ICH9_LPC_SMI_F_BROADCAST;
+  RequestedFeaturesMask = ICH9_LPC_SMI_F_BROADCAST;
+  if (!MemEncryptSevIsEnabled ()) {
+//
+// For now, we only support hotplug with SEV disabled.
+//
+RequestedFeaturesMask |= ICH9_LPC_SMI_F_CPU_HOTPLUG;
+  }
+  mSmiFeatures &= RequestedFeaturesMask;
QemuFwCfgSelectItem (mRequestedFeaturesItem);
QemuFwCfgWriteBytes (sizeof mSmiFeatures, );
  
@@ -144,6 +159,13 @@ NegotiateSmiFeatures (

  DEBUG ((DEBUG_INFO, "%a: using SMI broadcast\n", __FUNCTION__));
}
  
+  if ((mSmiFeatures &