Currently COMPAT16 section type is not recognized and GenSec is called
without the "-s [SectionType]" argument.
Add COMPAT16 type to the SectionType dictionary to fix the issue.
Now this syntax works correctly:
```
FILE FREEFORM = <GUID> {
SECTION COMPAT16 = <FILE>
}
```
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
EFI_SECTION_FREEFORM_SUBTYPE_GUID is a leaf section type that contains
a single EFI_GUID in the header to describe the raw data.
Currently is is not possible to generate such section.
This patch adds initial support for the generation of such sections.
The added syntax for this type of section corresponds to EDKII
"[FV] section" documentation from the FDF Specification:
```
SECTION SUBTYPE_GUID <GUID> = <File>
```
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Popen communication returns bytestrings. It is necessary to perform
decode on these strings before passing them to the EdkLogger that
works with ordinary strings.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The code changes add unit tests based on current UnitTestFramework.
EdkiiPeiMpServices2PpiPeiUnitTest PEI module is used to test
EdkiiPeiMpServices2Ppi and EfiMpServiceProtocolDxeUnitTest DXE driver is
used to test EfiMpServiceProtocol.
Signed-off-by: Jason Lou <yun.lou@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Add GENERAL_REGISTER.R8/R9 etc in EccCheck ExceptionList
of UefiCpuPkg/UefiCpuPkg.ci.yaml to pass CI EccCheck.R8/R9
in structure GENERAL_REGISTER of CpuExceptionHandlerTest.h
lead to EccCheck failure since no lower case characters in
R8/R9/R10 etc.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
The previous change adds unit test for DxeCpuExeptionHandlerLib
in 64bit mode. This change create a PEIM to add unit test for
PeiCpuExceptionHandlerLib based on previous change.It can run
in both 32bit and 64bit modes.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Add target based unit tests for the DxeCpuExceptionHandlerLib.
A DXE driver is created to test DxeCpuExceptionHandlerLib.
Four test cases are created in this Unit Test module:
a.Test if exception handler can be registered/unregistered
for no error code exception.In the test case, only no error
code exception is triggered and tested by INTn instruction.
b.Test if exception handler can be registered/unregistered
for GP and PF. In the test case, GP exception is triggered
and tested by setting CR4_RESERVED_BIT to 1. PF exception
is triggered by writting to not-present or RO address.
c.Test if CpuContext is consistent before and after exception.
In this test case:
1.Set Cpu register to mExpectedContextInHandler before
exception. 2.Trigger exception specified by ExceptionType.
3.Store SystemContext in mActualContextInHandler and set
SystemContext to mExpectedContextAfterException in handler.
4.After return from exception, store Cpu registers in
mActualContextAfterException.
The expectation is:
1.Register values in mActualContextInHandler are the same
with register values in mExpectedContextInHandler.
2.Register values in mActualContextAfterException are the
same with register values mActualContextAfterException.
d.Test if stack overflow can be captured by CpuStackGuard
in both Bsp and AP. In this test case, stack overflow is
triggered by a funtion which calls itself continuously.
This test case triggers stack overflow in both BSP and AP.
All AP use same Idt with Bsp. The expectation is:
1. PF exception is triggered (leading to a DF if sepereated
stack is not prepared for PF) when Rsp<=StackBase+SIZE_4KB
since [StackBase, StackBase + SIZE_4KB] is marked as not
present in page table when PcdCpuStackGuard is TRUE.
2. Stack for PF/DF exception handler in both Bsp and AP is
succussfully switched by InitializeSeparateExceptionStacks.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
If a device which support both features SR-IOV/ARI has multi
functions, which maybe support 8-255. After enable ARI forwarding in
the root port and ARI Capable Hierarchy in the SR-IOV PF0.
The device will support and expose multi functions(0-255) with ARI ID routing.
In next device loop in below for() code, actually it still be in the
same SR-IOV device, and just some PF which is over 8 or higher
one(n*8), PciAllocateBusNumber() will allocate bus
number(ReservedBusNum - TempReservedBusNum)) for this PF. if reset
TempReservedBusNum as 0 in this case,it will allocate wrong bus number
for this PF because TempReservedBusNum should be total previous PF's
reserved bus numbers.
code:
for (Device = 0; Device <= PCI_MAX_DEVICE; Device++) {
TempReservedBusNum = 0;
for (Func = 0; Func <= PCI_MAX_FUNC; Func++) {
//
// Check to see whether a pci device is present
//
Status = PciDevicePresent (
PciRootBridgeIo,
&Pci,
StartBusNumber,
Device,
Func
);
...
Status = PciAllocateBusNumber (PciDevice, *SubBusNumber,
(UINT8)(PciDevice->ReservedBusNum - TempReservedBusNum), SubBusNumber);
The solution is add a new flag IsAriEnabled to help handle this case.
if ARI is enabled, then TempReservedBusNum will not be reset again
during all functions(1-255) scan with checking flag IsAriEnabled.
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Below code will calculate the reserved bus number for the each PF.
Based on the VF routing ID algorithm, PFRid and LastVF in below code
already sure that "All VFs and PFs must have distinct Routing IDs".
PF will be assigned Routing ID based on secBusNumber, ReservedBusNum
will add into SubBusNumber directly. So the SR-IOV device will be
assigned bus range as SecBusNumber ~ (SubBusNumber=(SecBusNumber +
ReservedBusNum)).
Thus "+1" in below code will cause extra 1 bus, and introduce a bus hole.
PFRid = EFI_PCI_RID (Bus, Device, Func);
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride;
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) -
Bus + 1);
In SR-IOV spec, there is a note in section 2.1.2:
Note: Bus Numbers are a constrained resource. Devices are strongly
encouraged to avoid leaving ?holes? in their Bus Number usage to avoid
wasting Bus Numbers
So the issue can be fixed with below code change.
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) -
Bus);
https://bugzilla.tianocore.org/show_bug.cgi?id=4069
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
