Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apu2 uefi #1

Open
wants to merge 14 commits into
base: master
Choose a base branch
from
Open

Apu2 uefi #1

wants to merge 14 commits into from

Conversation

pietrushnic
Copy link
Member

This only for review purposes I do not plan to merge those changes in this repo.

Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
…aths for ConIn/ConOut/ErrOut

Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Prince Agyeman <prince.agyeman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
pietrushnic pushed a commit that referenced this pull request Nov 18, 2017
The new algorithm converts the problem calculating optimal
MTRR settings (using least MTRR registers) to the problem finding
the shortest path in a graph.
The memory required in extreme but rare case can be up to 256KB,
so using local stack buffer is impossible considering current
DxeIpl only allocates 128KB stack.

The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and
MtrrSetMemoryAttribute() to use the 4-page stack buffer for
calculation. The two APIs return BUFFER_TOO_SMALL when the buffer
is too small for calculation.

The patch adds a new API MtrrSetMemoryAttribute*s*InMtrrSettings() to
set multiple-range attributes in one function call.
Since every call to MtrrSetMemoryAttributeInMtrrSettings (without-s)
or MtrrSetMemoryAttribute() requires to calculate the MTRRs for the
whole physical memory, combining multiple calls in one API can
significantly reduce the calculation time.
In theory, if N times of call to without-s API costs N seconds,
the new API only costs 1 second.
The new API uses the buffer supplied from caller to calculate
MTRRs and returns BUFFER_TOO_SMALL when the buffer is too small for
calculation.

Test performed:
1. Random test
 a. Generate random memory settings, use the new algorithm to
    calculate the MTRRs.
 b. Read back the MTRRs and check the memory settings match
    the desired memory settings.
 c. Repeat the above #1 and #2 100000 times.
2. OVMF 32PEI + 64DXE boot to shell.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
BartekLew pushed a commit that referenced this pull request Feb 12, 2018
PerformancePkg contains following components:
1. TscTimerLib
2. Dp_App
3. Header files.

#1 has already been deprecated.
#2 can be removed because DpApp was added to ShellPkg.
#3 Header files are not used by DpApp and
   MdeModulePkg/PerformanceLib instances.

In summary, this package is no longer useful.

All related platforms have been updated to remove the references.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Daryl McDaniel <edk2-lists@mc2research.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
pietrushnic pushed a commit that referenced this pull request Feb 14, 2018
v2:
* Refine the commit log.

There are two place to close the ISCSI ExitBootServiceEvent:
#1.IScsiOnExitBootService(), which is the callback function of
   ExitBootServiceEvent.
#2.IScsiCleanDriverData(), which will be invoked by ISCSI driver
   binding stop().

So, the ExitBootServiceEvent will be closed and freed when exit boot
server is triggered. But it may be closed and freed again in ISCSI driver
binding stop(), which will result in the issue recorded at
https://bugzilla.tianocore.org/show_bug.cgi?id=742.

This patch is to resolve the issue.

Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
pietrushnic pushed a commit that referenced this pull request Feb 14, 2018
v2:
* Refine the commit log.

There are two place to close the ISCSI ExitBootServiceEvent:
#1.IScsiOnExitBootService(), which is the callback function of
   ExitBootServiceEvent.
#2.IScsiCleanDriverData(), which will be invoked by ISCSI driver
   binding stop().

So, the ExitBootServiceEvent will be closed and freed when exit boot
server is triggered. But it may be closed and freed again in ISCSI driver
binding stop(), which will result in the issue recorded at
https://bugzilla.tianocore.org/show_bug.cgi?id=742.

This patch is to resolve the issue.

Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
pietrushnic pushed a commit that referenced this pull request Apr 4, 2018
v2:
* Refine the commit log.

There are two place to close the ISCSI ExitBootServiceEvent:
#1.IScsiOnExitBootService(), which is the callback function of
   ExitBootServiceEvent.
#2.IScsiCleanDriverData(), which will be invoked by ISCSI driver
   binding stop().

So, the ExitBootServiceEvent will be closed and freed when exit boot
server is triggered. But it may be closed and freed again in ISCSI driver
binding stop(), which will result in the issue recorded at
https://bugzilla.tianocore.org/show_bug.cgi?id=742.

This patch is to resolve the issue.

Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
(cherry picked from commit d321598)
pietrushnic pushed a commit that referenced this pull request Apr 4, 2018
v2:
* Refine the commit log.

There are two place to close the ISCSI ExitBootServiceEvent:
#1.IScsiOnExitBootService(), which is the callback function of
   ExitBootServiceEvent.
#2.IScsiCleanDriverData(), which will be invoked by ISCSI driver
   binding stop().

So, the ExitBootServiceEvent will be closed and freed when exit boot
server is triggered. But it may be closed and freed again in ISCSI driver
binding stop(), which will result in the issue recorded at
https://bugzilla.tianocore.org/show_bug.cgi?id=742.

This patch is to resolve the issue.

Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
(cherry picked from commit a37c60b)
pietrushnic pushed a commit that referenced this pull request Apr 13, 2020
MpInitLib sets X2ApicEnable in two places.
1. CollectProcessorCount()
   This function is called when MpInitLibInitialize() hasn't been
   called before.
   It sets X2ApicEnable and later in the same function it configures
   all CPUs to operate in X2 APIC mode.
2. MpInitLibInitialize()
   The X2ApicEnable setting happens when this function is called in
   second time. But after that setting, no code consumes that flag.

With the above analysis and with the purpose of simplifying the code,
the X2ApicEnable in #1 is changed to local variable and the #2 can be
changed to remove the setting of X2ApicEnable.

Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Sakoram pushed a commit that referenced this pull request Oct 5, 2020
The unit test app supports running in 3 mode:
1. MtrrLibUnitTest generate-random-numbers
     <path to MtrrLib/UnitTest/RandomNumber.c> <random-number count>
   It generates random numbers and writes to RandomNumber.c.

2. MtrrLibUnitTest [<iterations>]
   It tests MtrrLib APIs using configurations generated from static
   numbers generated by mode #1.
   This is the default execution mode running in CI environment.

3. MtrrLibUnitTest <iterations> random
   It tests MtrrLib APIs using configurations generated from random
   numbers.
   This is what developers can use to test MtrrLib for regressions.

Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ming Shao <ming.shao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants