Anthony PERARD [Fri, 24 Jan 2020 17:49:20 +0000 (17:49 +0000)]
OvmfPkg/OvmfXen: Set PcdFSBClock
Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.
Currently, nothing appear to use the value in PcdFSBClock before
XenPlatformPei had a chance to set it even though TimerLib is included
in modules runned before XenPlatformPei.
XenPlatformPei doesn't use any of the functions that would use that
value. No other modules in the PEI phase seems to use the TimerLib
before PcdFSBClock is set. There are currently two other modules in
the PEI phase that needs the TimerLib:
- S3Resume2Pei, but only because LocalApicLib needs it, but nothing is
using the value from PcdFSBClock.
- CpuMpPei, but I believe it only runs after XenPlatformPei
Before the PEI phase, there's the SEC phase, and SecMain needs
TimerLib because of LocalApicLib. And it initialise the APIC timers
for the debug agent. But I don't think any of the DebugLib that
OvmfXen could use are actually using the *Delay functions in TimerLib,
and so would not use the value from PcdFSBClock which would be
uninitialised.
A simple runtime test showed that TimerLib doesn't use PcdFSBClock
value before it is set.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Anthony PERARD [Fri, 24 Jan 2020 15:23:23 +0000 (15:23 +0000)]
OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency
Calculate the frequency of the APIC timer that Xen provides.
Even though the frequency is currently hard-coded, it isn't part of
the public ABI that Xen provides and thus may change at any time. OVMF
needs to determine the frequency by an other mean.
Fortunately, Xen provides a way to determines the frequency of the
TSC, so we can use TSC to calibrate the frequency of the APIC timer.
That information is found in the shared_info page which we map and
unmap once done (XenBusDxe is going to map the page somewhere else).
The calculated frequency is only logged in this patch, it will be used
in a following patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
--- CC: Roger Pau Monné <roger.pau@citrix.com>
Anthony PERARD [Fri, 24 Jan 2020 15:38:13 +0000 (15:38 +0000)]
OvmfPkg/XenResetVector: Silent a warning from nasm
To avoid nasm generating a warning, replace the macro by the value
expected to be stored in eax.
Ia32/XenPVHMain.asm:76: warning: dword data exceeds bounds
Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Update PatchCheck to not enforce no tabs and not enforce CR/LF
line endings for .gitmodules files. These files are updated by
git when a git submodule command is used and the updates by git
use tab characters and LF line endings.
Also update patch check to not enforce CR/LF line endings for
patch lines that create a submodule directory. These patch
lines use LF line endings. The git submodule directory is
added as a new file with attributes 160000 that can be detected
by looking for the pattern "new file mode 160000".
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Hmac(Md5|Sha1|Sha256)GetContextSize() use a deprecated macro
HMAC_MAX_MD_CBLOCK defined in openssl. They should be dropped to
avoid misuses in the future. For context allocation and release,
use HmacXxxNew() and HmacXxxFree() instead.
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Xiaoyu Lu <xiaoyux.lu@intel.com>
HmacXxxInit() is supposed to be initialize user supplied buffer as HMAC
context, as well as user supplied key. Currently it has no real use cases.
Due to BZ1792, the user has no way to get correct size of context buffer
after it's fixed, and then cannot make use of HmacXxxInit to initialize
it.
So it's decided to replace it with HmacXxxSetKey to keep the functionality
of supplying a key to HMAC, but drop all other initialization works. The
user can still get HMAC context via HmacXxxNew interface, which hides the
details about the context.
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Xiaoyu Lu <xiaoyux.lu@intel.com>
Previous commit d786a17232:
UefiCpuPkg/MpInitLib: Reduce the size when loading microcode patches
Removed the below assignments for the 'InitFlag' field of CPU_MP_DATA
structure in function MpInitLibInitialize() when APs are waken up to do
some initialize sync:
The above commit mistakenly assumed the 'InitFlag' field will have a value
of 'ApInitDone' when the APs have been successfully waken up before. And
since there is no explicit comparision for the 'InitFlag' field with the
'ApInitReconfig' value. The commit removed those assignments.
However, under some cases (e.g. when variable OldCpuMpData is not NULL,
which means function CollectProcessorCount() will not be called), removing
the above assignments will left the 'InitFlag' field being uninitialized
with a value of 0, which is a invalid value for the type of 'InitFlag'
(AP_INIT_STATE).
It may potentially cause the WakeUpAP() function to run some unnecessary
codes when the APs have been successfully waken up before:
This commit will address the above-mentioned issue.
Test done:
* OS boot on a real platform with multi processors
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
Capsule Dependency is an incremental change of Fmp Capsule Update. The
capsule format is extended to include a set of binary encoded dependency
expression. The dependency expression is signed together with the Fmp
payload and evaluated before update is applied.
This feature is defined in UEFI Spec 2.8.
The dependency evaluation has two steps:
1. Validate platform existing Fmp images' version satisfy the dependency
expression in capsule image.
2. Validate the capsule image version satisfy all the platform existing
Fmp image's dependency expression.
If the dependency expression evaluates to FALSE, then the capsule update
fails and last attempt status is set to
LAST_ATTEMPT_STATUS_ERROR_UNSATISFIED_DEPENDENCIES.
The dependency saving and getting is FmpDeviceLib implementation scope.
The parameter "Image" of FmpDeviceSetImage and FmpDeviceGetImage function
is extended to contain the dependency. The layout:
+--------------------------+
| Dependency Op-codes |
+--------------------------+
| Fmp Payload Image |
+--------------------------+
1. FmpDeviceSetImage is responsible for retrieving the dependency from the
parameter "Image" and saving it to a protected storage.
2. FmpDeviceGetImage is responsible for retrieving the dependency from the
storage where FmpDeviceSetImage saves dependency and combining it with the
Fmp Payload Image into one buffer which is returned to the caller. This
dependency will be populated into EFI_FIRMWARE_IMAGE_DESCRIPTOR and used
for dependency evaluation.
3. FmpDeviceGetAttributes must set the bit IMAGE_ATTRIBUTE_DEPENDENCY to
indicate the Fmp device supports Fmp Capsule Dependency feature.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
1. Enhance "CapsuleApp -P" to output the depex expression op-codes in
the EFI_FIRMWARE_IMAGE_DESCRIPTOR.
2. Enhance Last Attempt Status String with a new string to describe the
error LAST_ATTEMPT_STATUS_ERROR_UNSATISFIED_DEPENDENCIES.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Add new definitions for Fmp Capsule dependency in UEFI Spec 2.8.
1. Extend the Last Attempt Status with a value to indicate the firmware
update fails with unsatisfied dependencies.
2. Add the definition of dependency expression op-codes.
3. Add the definition of EFI_FIRMWARE_IMAGE_DEP which is an array of FMP
dependency expression op-codes.
4. Extend the EFI_FIRMWARE_IMAGE_DESCRIPTOR with a pointer to the array of
FMP dependency expression op-codes.
5. Extend the Image Attribute Definitions with IMAGE_ATTRIBUTE_DEPENDENCY
to indicate that there is and EFI_FIRMWARE_IMAGE_DEP section associated
with the image.
6. Update EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION to 4.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
To increase the resiliency driver will now attempt to
retry the commands that failed due to the CRC error up
to 5 times. This should address the problems with the commands
that fail due to random condition on links. This should also
help the boards on which CMD13 is particularly unstable after
switching the link frequency.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Error detection function will now check if the command
failure has been caused by one of the errors that can
appear randomly on link(CRC error + end bit error). If
such an error has been a cause of failure, function will
return EFI_CRC_ERROR instead of EFI_DEVICE_ERROR to indicate
to the higher level that command has a chance of succeeding if
resent.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Albecki, Mateusz [Tue, 14 Jan 2020 12:05:27 +0000 (20:05 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Fix DAT lane SW reset
Driver used to reset the DAT lane on a current error which
is not required according to SD specification(it's not going
to help). This patch will reset the DAT lane only on DAT
lane specific errors.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Laszlo Ersek [Thu, 9 Jan 2020 21:00:39 +0000 (22:00 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: fix 2M->4K page splitting regression for PDEs
In commit 4eee0cc7cc0d ("UefiCpuPkg/PiSmmCpu: Enable 5 level paging when
CPU supports", 2019-07-12), the Page Directory Entry setting was regressed
(corrupted) when splitting a 2MB page to 512 4KB pages, in the
InitPaging() function.
Consider the following hunk, displayed with
$ git show --function-context --ignore-space-change 4eee0cc7cc0db
> //
> // If it is 2M page, check IsAddressSplit()
> //
> if (((*Pd & IA32_PG_PS) != 0) && IsAddressSplit (Address)) {
> //
> // Based on current page table, create 4KB page table for split area.
> //
> ASSERT (Address == (*Pd & PHYSICAL_ADDRESS_MASK));
>
> Pt = AllocatePageTableMemory (1);
> ASSERT (Pt != NULL);
>
> + *Pd = (UINTN) Pt | IA32_PG_RW | IA32_PG_P;
> +
> // Split it
> - for (PtIndex = 0; PtIndex < SIZE_4KB / sizeof(*Pt); PtIndex++) {
> - Pt[PtIndex] = Address + ((PtIndex << 12) | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
> + for (PtIndex = 0; PtIndex < SIZE_4KB / sizeof(*Pt); PtIndex++, Pt++) {
> + *Pt = Address + ((PtIndex << 12) | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
> } // end for PT
> *Pd = (UINT64)(UINTN)Pt | mAddressEncMask | PAGE_ATTRIBUTE_BITS;
> } // end if IsAddressSplit
> } // end for PD
First, the new assignment to the Page Directory Entry (*Pd) is
superfluous. That's because (a) we set (*Pd) after the Page Table Entry
loop anyway, and (b) here we do not attempt to access the memory starting
at "Address" (which is mapped by the original value of the Page Directory
Entry).
Second, appending "Pt++" to the incrementing expression of the PTE loop is
a bug. It causes "Pt" to point *right past* the just-allocated Page Table,
once we finish the loop. But the PDE assignment that immediately follows
the loop assumes that "Pt" still points to the *start* of the new Page
Table.
The result is that the originally mapped 2MB page disappears from the
processor's view. The PDE now points to a "Page Table" that is filled with
garbage. The random entries in that "Page Table" will cause some virtual
addresses in the original 2MB area to fault. Other virtual addresses in
the same range will no longer have a 1:1 physical mapping, but be
scattered over random physical page frames.
The second phase of the InitPaging() function ("Go through page table and
set several page table entries to absent or execute-disable") already
manipulates entries in wrong Page Tables, for such PDEs that got split in
the first phase.
This issue has been caught as follows:
- OVMF is started with 2001 MB of guest RAM.
- This places the main SMRAM window at 0x7C10_1000.
- The SMRAM management in the SMM Core links this SMRAM window into
"mSmmMemoryMap", with a FREE_PAGE_LIST record placed at the start of the
area.
- At "SMM Ready To Lock" time, PiSmmCpuDxeSmm calls InitPaging(). The
first phase (quoted above) decides to split the 2MB page at 0x7C00_0000
into 512 4KB pages, and corrupts the PDE. The new Page Table is
allocated at 0x7CE0_D000, but the PDE is set to 0x7CE0_E000 (plus
attributes 0x67).
- Due to the corrupted PDE, the second phase of InitPaging() already looks
up the PTE for Address=0x7C10_1000 in the wrong place. The second phase
goes on to mark bogus PTEs as "NX".
- PiSmmCpuDxeSmm calls SetMemMapAttributes(). Address 0x7C10_1000 is at
the base of the SMRAM window, therefore it happens to be listed in the
SMRAM map as an EfiConventionalMemory region. SetMemMapAttributes()
calls SmmSetMemoryAttributes() to mark the region as XP. However,
GetPageTableEntry() in ConvertMemoryPageAttributes() fails -- address
0x7C10_1000 is no longer mapped by anything! -- and so the attribute
setting fails with RETURN_UNSUPPORTED. This error goes unnoticed, as
SetMemMapAttributes() ignores the return value of
SmmSetMemoryAttributes().
- When SetMemMapAttributes() reaches another entry in the SMRAM map,
ConvertMemoryPageAttributes() decides it needs to split a 2MB page, and
calls SplitPage().
- SplitPage() calls AllocatePageTableMemory() for the new Page Table,
which takes us to InternalAllocMaxAddress() in the SMM Core.
- The SMM core attempts to read the FREE_PAGE_LIST record at 0x7C10_1000.
Because this virtual address is no longer mapped, the firmware crashes
in InternalAllocMaxAddress(), when accessing (Pages->NumberOfPages).
Remove the useless assignment to (*Pd) from before the loop. Revert the
loop incrementing and the PTE assignment to the known good version.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1789335 Fixes: 4eee0cc7cc0db74489b99c19eba056b53eda6358 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
This commit fixes an offset calculation that is used to write the
VarErrorFlag UEFI variable to the UEFI variable runtime cache.
Currently a physical address is used instead of an offset. This
commit changes the offset to zero with a length of the entire
non-volatile variable store so the entire non-volatile variable
store buffer in SMRAM (with the variable update modification) is
copied to the runtime variable cache. This follows the same pattern
used in other SynchronizeRuntimeVariableCache () calls for
consistency.
* Observable symptom: An exception in SMM will most likely occur
due to the invalid memory reference when the VarErrorFlag variable
is written. The variable is most commonly written when the UEFI
variable store is full.
* The issue only occurs when the variable runtime cache is enabled
by the following PCD being set to TRUE:
gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache
Fixes: aab3b9b9a1e5e1f3fa966fb1667fc3e6c47e7706 Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Michael Turner <michael.turner@microsoft.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Capsule generate tool support encode capsule dependencies through '-j'
command with a JSON file. To enable dependency feature, "Dependencies"
field for each payload in JSON file is required.
The value of "Dependencies" field is C style infix notation expression.
For example:
"Dependencies":"72E2945A-00DA-448E-9AA7-075AD840F9D4 > 0x00000001"
Ard Biesheuvel [Mon, 6 Jan 2020 11:38:29 +0000 (12:38 +0100)]
ArmPlatformPkg/PrePeiCore: enable VFP at startup
While the alternative PEI-less SEC implementation in PrePi already
takes the EnableVFP PCD into account, the PrePeiCore code does not,
and so we may end up triggering synchronous exception when code
attempts to use FP or SIMD registers, which is permitted on AARCH64
by the spec.
So enable the VFP as early as feasible if the associated PCD is set.
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib. Note that this means the hack to support warm
reboot by jumping to the SEC entry point with the MMU and caches off
is also no longer used, and can be removed as well, along with the PCD
PcdArmReenterPeiForCapsuleWarmReboot that was introduced for this
purpose.
Laszlo Ersek [Wed, 8 Jan 2020 22:24:02 +0000 (23:24 +0100)]
NetworkPkg/HttpDxe: fix 32-bit truncation in HTTPS download
When downloading over TLS, each TLS message ("APP packet") is returned as
a (decrypted) fragment table by EFI_TLS_PROTOCOL.ProcessPacket().
The TlsProcessMessage() function in "NetworkPkg/HttpDxe/HttpsSupport.c"
linearizes the fragment table into a single contiguous data block. The
resultant flat data block contains both TLS headers and data.
The HttpsReceive() function parses the actual application data -- in this
case: decrypted HTTP data -- out of the flattened TLS data block, peeling
off the TLS headers.
The HttpResponseWorker() function in "NetworkPkg/HttpDxe/HttpImpl.c"
propagates this HTTP data outwards, implementing the
EFI_HTTP_PROTOCOL.Response() function.
Now consider the following documentation for EFI_HTTP_PROTOCOL.Response(),
quoted from "MdePkg/Include/Protocol/Http.h":
> It is the responsibility of the caller to allocate a buffer for Body and
> specify the size in BodyLength. If the remote host provides a response
> that contains a content body, up to BodyLength bytes will be copied from
> the receive buffer into Body and BodyLength will be updated with the
> amount of bytes received and copied to Body. This allows the client to
> download a large file in chunks instead of into one contiguous block of
> memory.
Note that, if the caller-allocated buffer is larger than the
server-provided chunk, then the transfer length is limited by the latter.
This is in fact the dominant case when downloading a huge file (for which
UefiBootManagerLib allocated a huge contiguous RAM Disk buffer) in small
TLS messages.
For adjusting BodyLength as described above -- i.e., to the application
data chunk that has been extracted from the TLS message --, the
HttpResponseWorker() function employs the following assignment:
HttpMsg->BodyLength = MIN (Fragment.Len, (UINT32) HttpMsg->BodyLength);
The (UINT32) cast is motivated by the MIN() requirement -- in
"MdePkg/Include/Base.h" -- that both arguments be of the same type.
"Fragment.Len" (NET_FRAGMENT.Len) has type UINT32, and
"HttpMsg->BodyLength" (EFI_HTTP_MESSAGE.BodyLength) has type UINTN.
Therefore a cast is indeed necessary.
Unfortunately, the cast is done in the wrong direction. Consider the
following circumstances:
- "Fragment.Len" happens to be consistently 16KiB, dictated by the HTTPS
Server's TLS stack,
- the size of the file to download is 4GiB + N*16KiB, where N is a
positive integer.
As the download progresses, each received 16KiB application data chunk
brings the *next* input value of BodyLength closer down to 4GiB. The cast
in MIN() always masks off the high-order bits from the input value of
BodyLength, but this is no problem because the low-order bits are nonzero,
therefore the MIN() always permits progress.
However, once BodyLength reaches 4GiB exactly on input, the MIN()
invocation produces a zero value. HttpResponseWorker() adjusts the output
value of BodyLength to zero, and then passes it to HttpParseMessageBody().
HttpParseMessageBody() (in "NetworkPkg/Library/DxeHttpLib/DxeHttpLib.c")
rejects the zero BodyLength with EFI_INVALID_PARAMETER, which is fully
propagated outwards, and aborts the HTTPS download. HttpBootDxe writes the
message "Error: Unexpected network error" to the UEFI console.
For example, a file with size (4GiB + 197MiB) terminates after downloading
just 197MiB.
Invert the direction of the cast: widen "Fragment.Len" to UINTN.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Laszlo Ersek [Wed, 8 Jan 2020 20:19:35 +0000 (21:19 +0100)]
MdeModulePkg/UefiBootManagerLib: log reserved mem allocation failure
The LoadFile protocol can report such a large buffer size that we cannot
allocate enough reserved pages for. This particularly affects HTTP(S)
Boot, if the remote file is very large (for example, an ISO image).
While the TianoCore wiki mentions this at
<https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-image-size>:
> The maximum RAM disk image size depends on how much continuous reserved
> memory block the platform could provide.
it's hard to remember; so log a DEBUG_ERROR message when the allocation
fails.
(Manually rewrapped here for keeping PatchCheck.py happy.)
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com>
* Always print subject line after the git commit id to make
it easier to know the context of warnings or errors.
* Allow UTF-8 characters in subject line
* Error if subject line length > 75 without CVE-xxx-xxxxx present
* Error if subject line length > 92 with CVE-xxxx-xxxxx present
* If body line length is > 75, then print warning instead of error.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
BuildOption is used by TargetTxtClassObj.py
GenFdsOption is used by GenFds.py
When the GenFds tool is used alone (e.g. python3 -m GenFds.GenFds -h)
With the OptionParser function, the first detected function
prints the help message
import TargetTxtClassObj to GenFds,
The BuildOption will be executed and replace GenFdsOption
We removed all objects associated with this problem that
were created directly during the import process
(e.g. BuildOption, BuildTarget = MyOptionParser(),
TargetTxt = TargetTxtDict())
The Patch is going to fix this issue
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Siyuan Fu [Wed, 8 Jan 2020 03:22:30 +0000 (11:22 +0800)]
UefiCpuPkg: Shadow microcode patch according to FIT microcode entry.
The existing MpInitLib will shadow the microcode update patches from
flash to memory and this is done by searching microcode region specified
by PCD PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize.
This brings a limition to platform FW that all the microcode patches must
be placed in one continuous flash space.
This patch shadows microcode update according to FIT microcode entries if
it's present, otherwise it will fallback to original logic (by PCD).
A new featured PCD gUefiCpuPkgTokenSpaceGuid.PcdCpuShadowMicrocodeByFit
is added for enabling/disabling this support.
TEST: Tested on FIT enabled platform.
BZ: https://tianocore.acgmultimedia.com/show_bug.cgi?id=2449
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Siyuan Fu [Wed, 8 Jan 2020 03:14:38 +0000 (11:14 +0800)]
MdePkg: Add header file for Firmware Interface Table specification.
This patch add FirmwareInterfaceTable.h for the Firmware Interface Table
BIOS specification.
This is to remove future edk2 dependency on edk2-platforms repo. The file
content comes from
edk2-platforms\Silicon\Intel\IntelSiliconPkg\Include\IndustryStandard
link: https://tianocore.acgmultimedia.com/show_bug.cgi?id=2449 Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
BaseTools/PatchCheck.py: Let EmailAddressCheck describe email checked
We are checking different emails from the signature list. We are
going to check more. To be able to differency, add a description
field, so the error reported is clearer.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Jason Voelz [Mon, 23 Dec 2019 06:55:36 +0000 (14:55 +0800)]
MdePkg BaseLib.h: Update IA32_CR4 strut to include all public fields
Based on Intel Software Develeper's Manual, add all fields in IA32_CR4.
Signed-off-by: Jason Voelz <jason.voelz@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Currently, the TPM2 ACPI table is not produced, since we do not
incorporate the Tcg2Smm module, which implements the SMI based
physical presence interface exposed to the OS.
Add edk2 platform boot manager protocol which would have platform
specific refreshes to the auto enumerated as well as NV boot options
for the platform.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Siyuan, Fu [Fri, 3 Jan 2020 06:59:27 +0000 (14:59 +0800)]
UefiCpuPkg: Always load microcode patch on AP processor.
This patch updates the microcode loader to always perform a microcode
detect and load on both BSP and AP processor. This is to fix a potential
microcode revision mismatch issue in below situation:
1. Assume there are two microcode co-exists in flash: one production
version and one debug version microcode.
2. FIT loads production microcode to BSP and all AP.
3. UefiCpuPkg loader loads debug microcode to BSP, and skip the loading
on AP.
As a result, different microcode patches are loaded to BSP and AP, and
trigger microcode mismatch error during OS boot.
link: https://bugzilla.tianocore.org/show_bug.cgi?id=2431 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Siyuan Fu [Fri, 3 Jan 2020 07:11:51 +0000 (15:11 +0800)]
UefiCpuPkg: Remove alignment check when calculate microcode size.
This patch removes the unnecessary alignment check on microcode patch
TotalSize introduced by commit d786a172. The TotalSize has already been
checked with 1K alignment and MAX_ADDRESS in previous code as below:
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Current code use below loops to enumerate the CPUs:
for (Index = mMaxNumberOfCpus; Index-- > 0;) {
it has no issue but not easy for the developers to read the code.
Update above code to below style,
for (Index = 0; Index < mMaxNumberOfCpus; Index++) {
It make the developers easy to read and consistent with other
similar cases in this driver.
Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
Set the below two environment variables in edksetup.bat:
set CLANG_HOST_BIN=n
set CLANG_BIN=C:\Program Files\LLVM\bin\
In Windows, set CLANG_HOST_BIN=n to use nmake command
The CLANG_BIN is only be set if it is not defined.
Cc: Liming Gao <liming.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Yu-Chen Lin to have his/her name and email
address displayed properly in the git history.
Cc: Yu-Chen Lin <yuchenlin@synology.com> Reviewed-by: Yu-Chen Lin <yuchenlin@synology.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-33-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Vladimir Olovyannikov to have his/her name and
email address displayed properly in the git history.
Cc: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-31-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Star Zeng to have his/her name and email address
displayed properly in the git history.
Cc: Star Zeng <star.zeng@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-29-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Ray Ni to have his/her name and email address
displayed properly in the git history.
Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-26-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Nikolai Saoukh to have his/her name and email
address displayed properly in the git history.
Cc: Nikolai Saoukh <nms@otdel-1.org> Reviewed-by: Nikolai Saoukh <nms@otdel-1.org> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-24-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Ming Tan to have his/her name and email address
displayed properly in the git history.
Cc: Ming Tan <ming.tan@intel.com> Reviewed-by: Ming Tan <ming.tan@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-23-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Michael Kubacki to have his/her name and email
address displayed properly in the git history.
Cc: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Michael Kubacki <michael.a.kubacki@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-22-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Maurice Ma to have his/her name and email
address displayed properly in the git history.
Cc: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-21-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Maciej Rabeda to have his/her name and email
address displayed properly in the git history.
Cc: Maciej Rabeda <maciej.rabeda@intel.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-18-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Jim Dailey to have his/her name and email
address displayed properly in the git history.
Cc: Jim Dailey <Jim.Dailey@Dell.com> Reviewed-by: Jim Dailey <Jim.Dailey@Dell.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-15-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Jiewen Yao to have his/her name and email
address displayed properly in the git history.
Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-14-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Hot Tian to have his/her name and email address
displayed properly in the git history.
Cc: Hot Tian <hot.tian@intel.com> Reviewed-by: Hot Tian <hot.tian@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-13-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Erik Bjorge to have his/her name and email
address displayed properly in the git history.
Cc: Erik Bjorge <erik.c.bjorge@intel.com> Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-11-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Eric Dong to have his/her name and email
address displayed properly in the git history.
Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-10-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Antoine Cœur to have his/her name and email
address displayed properly in the git history.
Cc: Antoine Cœur <coeur@gmx.fr> Reviewed-by: Antoine Cœur <coeur@gmx.fr> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-4-philmd@redhat.com>
[lersek@redhat.com: fix up valid PatchCheck.py error in Reviewed-by]
[lersek@redhat.com: translit subject to ASCII to suppress PatchCheck.py]
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Aaron Li to have his/her name and email address
displayed properly in the git history.
Cc: Aaron Li <aaron.li@intel.com> Cc: Songpeng Li <songpeng.li@intel.com> Reviewed-by: Aaron Li <aaron.li@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-3-philmd@redhat.com>
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction IN
as required to set up an asynchronous interrupt transfer.
Currently, the driver assumes that the first INT endpoint
will be of type IN, but that is not true of all devices,
and will silently fail on devices which have the OUT endpoint
before the IN. Adjust the endpoint selection loop to explictly
check for direction IN.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
MrChromebox [Mon, 6 Jan 2020 04:12:06 +0000 (12:12 +0800)]
MdeModulePkg/Usb/UsbMouse: Fix endpoint selection
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction IN
as required to set up an asynchronous interrupt transfer.
Currently, the driver assumes that the first INT endpoint
will be of type IN, but that is not true of all devices,
and will silently fail on devices which have the OUT endpoint
before the IN. Adjust the endpoint selection loop to explictly
check for direction IN.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: GuoMinJ <newexplorerj@gmail.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
MrChromebox [Mon, 6 Jan 2020 04:12:05 +0000 (12:12 +0800)]
MdeModulePkg/Usb/EfiKey: Fix endpoint selection
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction IN
as required to set up an asynchronous interrupt transfer.
Currently, the driver assumes that the first INT endpoint
will be of type IN, but that is not true of all devices,
and will silently fail on devices which have the OUT endpoint
before the IN. Adjust the endpoint selection loop to explictly
check for direction IN.
Test: detachable keyboard on Google Pixel Slate now works.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: GuoMinJ <newexplorerj@gmail.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Report EV_EFI_HANDOFF_TABLES2 if the platform chooses PFP >= 105.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
In current implementation, the SMBIOS table is measured multiple
time in every readytoboot event.
This causes Smbios Table record appears multiple time in the TCG event log
and confuses people.
This issue makes it hard to implement 800-155 reference measurement.
This patch closes the event to make sure Smbios is measured only once.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Albecki, Mateusz [Fri, 20 Dec 2019 17:13:12 +0000 (01:13 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Add function to start SD clock
In SD card voltage switch flow we used to redo the
entire internal clock setup after voltage switch.
Since internal clock has already been setup this
is wasting time on polling the internal clock stable.
This commit changes it to only start the SD clock.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Marcin Wojtas <mw@semihalf.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Albecki, Mateusz [Fri, 20 Dec 2019 17:13:11 +0000 (01:13 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Hook SwitchClockFreq after SD clock start
For eMMC modules we used to notify the platform about frequency
change only after sending CMD13 which meant that platform
might not get a chance to apply required post frequency
change fixes to get the clock stable. To fix this
notification has been moved to SdMmcHcClockSupply function
just after we start the SD clock. During first time setup
the notification won't be sent to avoid changing old behavior.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Marcin Wojtas <mw@semihalf.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
projects / people / aperard / ovmf.git / log