Date 1 - 2 of 2
回复: [edk2-devel] Soft Feature Freeze starts now for edk2-stable202102
Hi, Stewards and All:
So far, there are still three patch sets to be requested to catch this
stable tag. They are bug fixes, and pass code review in soft feature freeze
phase. Have you any comments for them?
1. Fix two issue in ArmGicLib
2. Fix CET shadow stack token busy bit clear issue
[Liming] this version uses DB for the instruction. BZ
https://bugzilla.tianocore.org/show_bug.cgi?id=3227 is create for future
3. Use XADD to avoid lock acquire/release
<email@example.com> 代表 gaoliming
发送时间: 2021年2月22日 16:23
收件人: firstname.lastname@example.org; email@example.com
抄送: 'Andrew Fish' <afish@...>; 'Laszlo Ersek' <lersek@...>;
leif@...; 'Michael D Kinney' <michael.d.kinney@...>; 'Soumya
主题: [edk2-devel] Soft Feature Freeze starts now for edk2-stable202102
We will enter into Soft Feature Freeze phase. In this phase, the feature
under review will not be allowed to be merged. The feature passed review can
still be merged.
The patch review can continue 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-stable202102 key words in the patch title and BZ, so the
community know this patch target and give the feedback.
Below is edk2-stable202102 tag planning
g Proposed Schedule
Date (00:00:00 UTC-8) Description
2020-11-27 Beginning of development
2021-02-15 Feature Planning Freeze
2021-02-22 Soft Feature Freeze
2021-03-01 Hard Feature Freeze
On 02/26/21 07:27, gaoliming wrote:
Hi, Stewards and All:I agree that the first two patch sets are bugfixes, but I'm not entirely
convinced the third one is a bugfix as well -- it is a performance
optimization, to my understanding. Without that patch set, there is no
misbehavior, things are just slower.
The bugfixes can be merged of course; I wouldn't merge the 3rd series
... I can see Ray pushed the first patch of the third series:
I disagree with that. Here's an excerpt from the commit message:
With this patch, OVMF when running in a 255 threads QEMU spends about
one second to wakeup all APs. Original implementation needs more than
I wouldn't call the pre-patch behavior a bug.
And the review for "[PATCH v3 1/4] UefiCpuPkg/MpInitLib: Use XADD to
avoid lock acquire/release" only arrived (from Mike) after the SFF, so I
don't think it should have been pushed.
On the other hand, I also won't ask for a revert.
|1 - 2 of 2|