To consume FIT table for Microcode update,
UefiCpuPkg/Feature/Capsule/MicrocodeUpdateDxe
needs to be updated to consume
IntelSiliconPkg/Include/IndustryStandard/FirmwareInterfaceTable.h,
but UefiCpuPkg could not depend on IntelSiliconPkg.
Since the Microcode update feature is specific to Intel,
we can first move the Microcode update feature code from
UefiCpuPkg to IntelSiliconPkg [first step], then update
the code to consume FIT table [second step].
This patch series is for the first step.
Note: No any code change in this patch, just move.
Next patch will update MicrocodeUpdate to build with the package.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
Julien Grall [Wed, 29 Nov 2017 17:28:23 +0000 (01:28 +0800)]
MdeModulePkg/SerialDxe: Do not fail reset when SetAttributes is not supported
After commit 91cc526b15 "MdeModulePkg/SerialDxe: Fix not able to change
serial attributes", serial is initialized using the reset method that
will call SetAttributes.
However, SetAttributes may return EFI_INVALID_PARAMETER when a driver
does not support some parameters. This will be propagated by the reset
function and lead to UEFI failing to get the console setup.
For instance, this is the case when using the Xen console driver.
Fix it by introspecting the result and return EFI_SUCCESS when the
SetAttributes report an invalid parameter (i.e EFI_INVALID_PARAMETER).
Julien Grall [Wed, 29 Nov 2017 17:28:22 +0000 (01:28 +0800)]
MdeModulePkg/SerialDxe: Fix return valued in SerialSetAttributes
SerialSetAttributes is meant to match the behavior of the function
EFI_SERIAL_IO_PROTOCOL.SetAttributes() in the UEFI spec (v2.7). This
means the function can only return:
- EFI_SUCCESS
- EFI_INVALID_PARAMETER
- EFI_DEVICE_ERROR
However the function SerialPortSetAttributes may also validly return
EFI_UNSUPPORTED. For instance this is the case of the Xen Console
driver.
EFI_UNSUPPORTED could be also interpreted as "One or more of the attributes
has an unsupported value". So return EFI_INVALID_PARAMETER in that case.
Lastly, to prevent another return slipping in the future, all the errors
but EFI_INVALID_PARAMETER and EFI_UNSUPPORTED will return
EFI_DEVICE_ERROR.
DXE performance gauge record access functions might be reentered since
we are supporting something like USB hot-plug, which is a timer event
where gBS->ConnectController might be called and then PERF will be
called in CoreConnectSingleController.
When StartGaugeEx is being reentered, not only the gauge record might
be overwritten, more serious situation will be caused if gauge data
buffer reallocation procedure is interrupted, between line 180 and 187
in DxeCorePerformanceLib.c specifically. There, mMaxGaugeRecords will
be doubled twice (denoted as 4X), but mGaugeData only points to a
buffer of size 2X, which will probably cause the following 2X memory
to be overflowed when gauge records are increased.
So we add EFI lock with TPL_NOTIFY in StartGaugeEx/EndGaugeEx/GetGaugeEx
to avoid memory overflow and gauge data corruption.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Dandan Bi [Tue, 28 Nov 2017 03:44:34 +0000 (11:44 +0800)]
PcAtChipsetPkg: Add description for new added PCD in commit e78aab9d2
Cc: Leo Duran <leo.duran@amd.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Chasel, Chiu [Thu, 23 Nov 2017 02:22:45 +0000 (10:22 +0800)]
IntelFsp2WrapperPkg: Support UPD allocation outside FspWrapper
UPD allocation and patching can be done outside FspWrapper
as implementation choice so adding a PCD to select between
original FspWrapper allocation model or outside model
Cc: Jiewen Yao <Jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Ruiyu Ni [Tue, 28 Nov 2017 08:35:06 +0000 (16:35 +0800)]
OvmfPkg: Add tftp dynamic command
The TFTP command was converted from a NULL class library instance
to a dynamic shell command in commit 0961002352e9.
This patch complements commit f9bc2f876326, which only removed the
old library, but didn't add the new dynamic command。
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org>
Ruiyu Ni [Tue, 28 Nov 2017 08:27:43 +0000 (16:27 +0800)]
CorebootPayloadPkg: Fix build failure due to Tftp/Dp library removal
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Prince Agyeman <prince.agyeman@intel.com> Reviewed-by: Benjamin You <benjamin.you@intel.com>
Ruiyu Ni [Mon, 27 Nov 2017 01:38:08 +0000 (09:38 +0800)]
OvmfPkg/Sec: Fix 64bit SEC build failure
Original code breaks a single assembly code to multiple lines.
But, when VS CL.exe preprocesses the FixedPcdGet32() macro
invocation to the replacement text, it loses '\', and causes
NASM to fail.
Changing the multiple lines to one line to resolve the build failure.
Ruiyu Ni [Tue, 28 Nov 2017 11:43:16 +0000 (19:43 +0800)]
ShellPkg/DynamicCommand: Fix bug that cannot start in boot
When dynamic command drivers are built into FV and start during
boot, they fails. Because Shell protocol doesn't exist during boot.
The patch sets Shell protocol and also set PcdShellLibAutoInitialize
to FALSE to ensure that
1. Shell protocol check doesn't happen in driver's entry point.
2. Driver can get the Shell protocol in DynamicCommand.Handler().
Ruiyu Ni [Tue, 28 Nov 2017 11:38:39 +0000 (19:38 +0800)]
ShellPkg/ShellLib: Fix dynamic command fails to start during boot
The previous change in ShellLib: "commit 3d29f8c5e361525a0d2accfa7f5bb0a7210b8927
* ShellPkg/ShellLib: Constructor doesn't depend on ShellParameters"
resolved the issue when loading dynamic command driver from Shell
environment.
But when dynamic command driver is built into FV and started during
boot, the driver still fails to start because Shell protocol doesn't
exist at that time.
The patch changes ShellLib to:
1. Do not look for Shell and ShellParameters protocol when they are
non-NULL in ShellLibConstructorWorker();
The two protocols are assumed to be set by DynamicCommand.Handler.
When ShellInitialize() is called in DynamicCommand.Handler, this
change can prevent the two protocols to be changed to NULL by
the locating logic.
2. Do not reset the Shell and ShellParameters protocol to NULL in
ShellLibDestructor() when CloseProtocol() fails;
Dynamic command driver needs to set the PcdShellLibAutoInitialize
to FALSE in order to skip the constructor.
Current logic calls ShellLibDestructor() when the PCD is FALSE when
ShellInitialize() is called. The change prevent the two protocols
to be changed to NULL.
The two changes don't impact existing usage case so they are backward
compatible.
Ruiyu Ni [Tue, 28 Nov 2017 09:06:32 +0000 (17:06 +0800)]
ShellPkg: Fix the bug that handling Ctrl-C improperly
Current implementation resets the CTRL-C event early when printing
the shell prompt, when user types "<CTRL-C>ls<ENTER>", "ls" command
is terminated immediately when starts.
It's not an expected behavior from users' perspective.
Correct way is to reset the CTRL-C event just before running the
command, which is a bit later than current point.
Ruiyu Ni [Mon, 27 Nov 2017 01:17:24 +0000 (09:17 +0800)]
MdeModulePkg/AtaAtapiPassThru: Revert patch to disable PCI attributes
This patch caused Windows 10 S4 resume failure.
Considering the similar changes are reverted from PciBus driver,
revert the patch from AtaAtapiPassThru as well.
Revert "MdeModulePkg/AtaAtapiPassThru: disable the device
at ExitBootServices()"
Ruiyu Ni [Mon, 27 Nov 2017 01:13:51 +0000 (09:13 +0800)]
MdeModulePkg/AtaAtapiPassThru: Revert patch to disable Bus Master
This patch caused Windows 10 S4 resume failure.
Considering the similar changes are reverted from PciBus driver,
revert the patch from AtaAtapiPassThru as well.
Laszlo Ersek [Thu, 23 Nov 2017 21:32:19 +0000 (22:32 +0100)]
OvmfPkg/QemuBootOrderLib: let an OFW devpath match multiple UEFI boot opts
This means that SetBootOrderFromQemu() will preserve all UEFI boot options
matched by any given OFW devpath, such as PXEv4, HTTPv4, PXEv6 and HTTPv6
boot options for the same NIC. Currently we stop the matching / appending
for the OFW devpath coming from the outer loop whenever we find the first
UEFI boot option match in the inner loop.
(The previous patch was about multiple OFW devpaths matching a single UEFI
boot option (which should never happen). This patch is about a single OFW
devpath matching multiple UEFI boot options. With the "break" statement
removed here, the small optimization from the last patch becomes a bit
more relevant, because now the inner loop always counts up to
ActiveCount.)
The SetBootOrderFromQemu() function implements a nested loop where
- the outer loop iterates over all OpenFirmware (OFW) device paths in the
QEMU boot order, and translates each to a UEFI device path prefix;
- the inner loop matches the current (translated) prefix against all
active UEFI boot options in turn;
- if the UEFI boot option is matched by the translated prefix, the UEFI
boot option is appended to the "new" UEFI boot order, and marked as
"has been appended".
This patch adds a micro-optimization where already matched / appended UEFI
boot options are skipped in the inner loop. This is not a functional
change. A functional change would be if, as a consequence of the patch,
some UEFI boot options would no longer be *doubly* matched.
For a UEFI boot option to be matched by two translated prefixes, one of
those prefixes would have to be a (proper, or equal) prefix of the other
prefix. The PCI and MMIO OFW translation routines output such only in the
following cases:
- When the original OFW device paths are prefixes of each other. This is
not possible from the QEMU side. (Only leaf devices are bootable.)
- When the translation rules in the routines are incomplete, and don't
look at the OFW device paths for sufficient length (i.e., at nodes where
they would already differ, and the difference would show up in the
translation output).
This would be a shortcoming of the translation routines and should be
fixed in TranslatePciOfwNodes() and TranslateMmioOfwNodes(), whenever
identified.
Even in the second case, this patch would replace the double appending of
a single UEFI boot option (matched by two different OFW device paths) with
a correct, or cross-, matching of two different UEFI boot options. Again,
this is not expected, but arguably it would be more correct than duplicate
boot option appending, should it occur due to any (unexpected, unknown)
lack of detail in the translation routines.
Ruiyu Ni [Fri, 24 Nov 2017 09:26:24 +0000 (17:26 +0800)]
ShellPkg/dp: Convert from NULL class library to Dynamic Command
UEFI Shell spec defines Shell Dynamic Command protocol which is just
for the purpose to extend internal command.
So dp command is changed from NULL class library to be a driver
producing DynamicCommand protocol.
The guideline is:
1. Only use NULL class library for Shell spec defined commands.
2. New commands can be provided as not only a standalone application
but also a dynamic command. So it can be used either as an
internal command, but also as a standalone application.
DpApp.inf is to provide a standalone application.
DpDynamicCommand.inf is to provide a standalone driver producing
Dynamic Command protocol.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ruiyu Ni [Tue, 31 Oct 2017 02:47:31 +0000 (10:47 +0800)]
ShellPkg/tftp: Convert from NULL class library to Dynamic Command
UEFI Shell spec defines Shell Dynamic Command protocol which is just
for the purpose to extend internal command.
So tftp command is changed from NULL class library to be a driver
producing DynamicCommand protocol.
The guideline is:
1. Only use NULL class library for Shell spec defined commands.
2. New commands can be provided as not only a standalone application
but also a dynamic command. So it can be used either as an
internal command, but also as a standalone application.
TftpApp.inf is to provide a standalone application.
TftpDynamicCommand.inf is to provide a standalone driver producing
Dynamic Command protocol.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ruiyu Ni [Fri, 24 Nov 2017 08:01:41 +0000 (16:01 +0800)]
ShellPkg/ShellLib: Constructor doesn't depend on ShellParameters
When ShellLib is linked to a driver producing DynamicCommand
protocol, ShellParameters protocol is set by
DynamicCommand.Handler().
The driver image handle doesn't have ShellParameters protocol
installed.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Jian J Wang [Thu, 23 Nov 2017 01:57:01 +0000 (09:57 +0800)]
MdeModulePkg/Core: Merge memory map after filtering paging capability
Once the paging capabilities were filtered out, there might be some adjacent entries
sharing the same capabilities. It's recommended to merge those entries for the OS
compatibility purpose.
This patch makes use of existing method MergeMemoryMap() to do it. This is done by
simply turning this method from static to extern, and call it after filter code.
This patch is related to an issue described at
https://bugzilla.tianocore.org/show_bug.cgi?id=753
This patch is also passed test of booting follow OSs:
Windows 10
Windows Server 2016
Fedora 26
Fedora 25
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
Ard Biesheuvel [Fri, 24 Nov 2017 09:43:50 +0000 (09:43 +0000)]
ArmVirtPkg/PrePi: don't export PE/COFF and LZMA libraries via HOBs
The PrePi code we inherited from ArmPlatformPkg contains a rather
obscure optimization, where entry points of the PE/COFF and LZMA
handling routines are recorded in special HOBs, allowing DXE core
to call into that code directly rather than carry its own copy of
these libraries.
Given that no ArmVirtPkg platforms actually include the library
resolutions* that take advantage of these optimizations, let's not
bother with them, and remove the associated code.
Laszlo Ersek [Wed, 22 Nov 2017 16:48:38 +0000 (17:48 +0100)]
MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before hanging
Under the following scenario:
- no UEFI bootable application available anywhere in the system,
- ... not even for the default platform recovery option,
- no shell is built into the firmware image,
- but UiApp is available in the firmware image,
we should preferably not just hang in BdsEntry() with:
DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
CpuDeadLoop ();
while the user sits at the TianoCore logo page, wondering what's going on.
Print an informative message to the console, wait for a keypress, and then
return to the Boot Manager Menu forever.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Star Zeng <star.zeng@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=513 Suggested-by: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
chenc2 [Mon, 20 Nov 2017 07:34:17 +0000 (15:34 +0800)]
SecurityPkg/SecureBootConfigDxe: Fix deleting signature data issue.
Replace "(UINT8 *)NewVariableData" with (UINT8 *)NewVariableData + Offset"
to avoid the header of EFI_SIGNATURE_LIST being copied to the front of
NewVariableData every time and update ListWalker when handling the current
EFI_SIGNATURE_LIST finishes.
Ard Biesheuvel [Wed, 15 Nov 2017 15:36:07 +0000 (15:36 +0000)]
EmbeddedPkg Omap35xxPkg: remove EBL and associated libraries
EBL is a deprecated, small memory footprint alternative for the
UEFI Shell that is no longer in use by any platforms in EDK2 or
in edk2-platforms. To avoid confusion, let's remove it from the
tree.
This module is not used anywhere under edk2 or edk2-platforms, so let's
remove it. This removes the only dependency on ArmPlatformLib from ArmPkg.
While at it, remove a mention of ArmPlatformPkg from a comment in the
.dec file as well.
Leif Lindholm [Sat, 25 Nov 2017 13:16:20 +0000 (13:16 +0000)]
EmbeddedPkg: get rid of BdsLib dependency from Android*Boot
The sum use these applications made of BdsLib was one invocation of the
IS_DEVICE_PATH_NODE macro, and (incorrectly) being able to leave out a
dependency on gEfiLoadedImageProtocolGuid.
So expand the macro in place and add the missing dependency.
Then clean up the .dsc, .inf and #includes accordingly.
Gary Lin [Wed, 22 Nov 2017 04:43:56 +0000 (12:43 +0800)]
CryptoPkg/IntrinsicLib: Fix the warning on memset
Gcc issued the warning when compiling CryptoPkg:
CryptoPkg/Library/Include/CrtLibSupport.h:135:17: warning: type of 'memset' does not match original declaration [-Wlto-type-mismatch]
void *memset (void *, int, size_t);
^
CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c:27:8: note: type mismatch in parameter 2
void * memset (void *dest, char ch, size_t count)
^
This commit changes the type of ch from char to int to match the
declaration.
Cc: Qin Long <qin.long@intel.com> Cc: Ting Ye <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Qin Long <qin.long@intel.com>
Jian J Wang [Thu, 23 Nov 2017 01:48:33 +0000 (09:48 +0800)]
MdeModulePkg/DxeCore: Filter out all paging capabilities
Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
set attributes and change memory paging attribute accordingly.
But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
value from Capabilities in GCD memory map. This might cause
boot problems. Clearing all paging related capabilities can
workaround it. The code added in this patch is supposed to
be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
is clarified in UEFI spec and adopted by both EDK-II Core and
all supported OSs.
Laszlo did a thorough test on OVMF emulated platform. The details
can be found at
https://bugzilla.tianocore.org/show_bug.cgi?id=753#c10
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Jian J Wang [Mon, 23 Oct 2017 06:49:02 +0000 (14:49 +0800)]
UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map
More than one entry of RT_CODE memory might cause boot problem for some
old OSs. This patch will fix this issue to keep OS compatibility as much
as possible.
More detailed information, please refer to
https://bugzilla.tianocore.org/show_bug.cgi?id=753
Laszlo did a thorough test on OVMF emulated platform. The details can be found
at
https://bugzilla.tianocore.org/show_bug.cgi?id=753#c10
Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Jiaxin Wu [Fri, 17 Nov 2017 03:50:11 +0000 (11:50 +0800)]
CryptoPkg/TlsLib: Change the return type of TlsInitialize().
V2:
* Correct the commit log.
Currently, the return code of OPENSSL_init_ssl(0 or 1) and RandomSeed
(TRUE or FALSE) are not checked in TlsInitialize(). Also "VOID" is used
as the return type of TlsInitialize(), which can't be used to capture
the returned value for error handling.
From Long Qin (CryptoPkg owner):
The early version of OPENSSL_init_ssl() use the "VOID" as the return
value, which was updated to "int" later because the function changes
can fail.
So, this patch is to change the return type of TlsInitialize() to
follow up the OPENSSL_init_ssl() update.
Cc: Ye Ting <ting.ye@intel.com> Cc: Long Qin <qin.long@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: Long Qin <qin.long@intel.com>
Jian J Wang [Thu, 23 Nov 2017 00:56:46 +0000 (08:56 +0800)]
MdeModulePkg/Core: Fix potential array overflow
In the method DumpGuardedMemoryBitmap() and SetAllGuardPages(), the code
didn't check if the global mMapLevel is legal value or not, which leaves
a logic hole causing potential array overflow in code followed.
This patch adds sanity check before any array reference in those methods.
Cc: Wu Hao <hao.a.wu@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Wu Hao <hao.a.wu@intel.com>
Jian J Wang [Thu, 23 Nov 2017 01:17:49 +0000 (09:17 +0800)]
MdeModulePkg/Core: Add missing header files into inf
The coding style requires that header files must be also added in module's inf
file, as long as they're included by c files. This patch will fix this issue.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Jiaxin Wu [Wed, 22 Nov 2017 06:34:30 +0000 (14:34 +0800)]
NetworkPkg/HttpDxe: Fix the incorrect SizeofHeaders in HttpTcpReceiveHeader().
Commit 19bd133562df951ae7ff7e1fff99b11a25b4cb6d is to fix the incorrect SizeofHeaders
returned from HttpTcpReceiveHeader(). But it missed the "\r\n\r\n" calculation, which
will cause the later HttpHeaders parsing failure.
This patch is fix the above 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>
Ard Biesheuvel [Wed, 22 Nov 2017 09:41:44 +0000 (09:41 +0000)]
ArmVirtPkg: create QemuVirtMemInfoLib version for ArmVirtQemu
The QemuVirtMemInfoLib ArmVirtMemInfoLib implementation created for
ArmVirtQemuKernel does exactly what we need for ArmVirtQemu, the only
difference being that the latter is PrePeiCore based, and so it uses
a different method to ensure that PcdSystemMemorySize is set when
ArmVirtGetMemoryMap() is called.
On ArmVirtQemu, we currently abuse the implied ordering guarantees
provided by ArmPlatformLib, by implementing this as follows:
ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf [ArmVirtPkg/ArmVirtQemu.dsc]
InitializeMemory() [ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c]
ArmPlatformInitializeSystemMemory() [ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c]
//
// set PcdSystemMemorySize from the DT
//
MemoryPeim() [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
InitMmu() [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
ArmPlatformGetVirtualMemoryMap() [ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c]
//
// consume PcdSystemMemorySize
//
Given that we are trying to get rid of ArmPlatformLib, or at least remove
some of these API functions that are never used for their original purpose
by any platforms, we need to move the PCD assignment elsewhere.
So create a PEIM-only version of QemuVirtMemInfoLib especially for
ArmVirtQemu, and add the PCD assignment code to its constructor.
Create a new ArmVirtMemInfoLib for ArmVirtQemuKernel by cloning the
existing ArmPlatformGetVirtualMemoryMap () for this platform,
(ArmQemuRelocatablePlatformLib *not* ArmVirtPlatformLib), and cleaning
it up:
- remove support for uncached DRAM mappings
- replace EFI_D_xxx with DEBUG_xxx throughout
- use a temp variable to hold the top of the physical address space
- use AllocatePool () instead of AllocatePages (), given that we use
160 bytes only, and the memory is never freed.
In a future patch, we will add this library to the ordinary ArmVirtQemu
platform as well.
Clone the existing ArmPlatformGetVirtualMemoryMap () for this platform,
clean it up slightly (by using a static buffer rather than a heap
allocation, and removing the support for uncached DRAM mappings), and
turn it into a new ArmVirtMemInfoLib implementation.
Ard Biesheuvel [Fri, 17 Nov 2017 13:55:17 +0000 (13:55 +0000)]
ArmVirtPkg: introduce ArmVirtMemInfoLib library class
As part of the effort to get rid of ArmPlatformLib (which incorporates
far too many duties in a single library), introduce ArmVirtMemInfoLib
which will be invoked by our ArmVirtMemoryInitPeiLib implementation to
get a description of the virtual address space. This will allow us to
remove this functionality from ArmPlatformLib later, or, in the case of
ArmVirtXen and ArmVirtQemuKernel, drop ArmPlatformLib altogether.
Ard Biesheuvel [Fri, 17 Nov 2017 13:33:15 +0000 (13:33 +0000)]
ArmVirtPkg/ArmVirtPlatformLib: remove support for uncached mappings
QEMU/KVM has very little tolerance for using anything except writeback
cacheable mappings of DRAM, so let's remove the 'feature' that allows
us to select uncached mappings at build time.
ArmPlatformStackLib has hooks into primary/secondary core PCDs and
other ArmPlatformLib related junk, so let's simply set the stack
pointer directly. This is trivial given that our PrePi is unicore
only.
Ard Biesheuvel [Fri, 17 Nov 2017 11:09:44 +0000 (11:09 +0000)]
ArmVirtPkg/PrePi: move DRAM discovery code into PrePi
ArmVirtQemuKernel and ArmVirtXen use essentially the same code to
retrieve DRAM information from the DT /memory node at early boot,
and invoke it via the ArmPlatformPeiBootAction () hook exposed by
ArmPlatformLib. Let's move this code into the PrePi implementation
these platforms share between them (and not with any other platforms)
so we can eliminate another dependency on the messy ArmPlatformLib.
Ard Biesheuvel [Fri, 17 Nov 2017 10:54:59 +0000 (10:54 +0000)]
ArmVirtPkg/PrePi: remove bogus primary core check
QEMU and KVM based ARM/AARCH64 virtual machines only enter UEFI on
a single core, so ArmPlatformIsPrimaryCore() always returns true.
And even if it didn't, our code does absolutely nothing meaningful
based on its return value, so don't bother calling it, and remove
another frivolous dependency on ArmPlatformLib.
Ard Biesheuvel [Mon, 13 Nov 2017 15:09:30 +0000 (15:09 +0000)]
ArmVirtPkg/PrePi: run all library constructors by hand
Instead of invoking the library constructors of some libraries by
hand, invoke the generated function ProcessLibraryConstructorList
in AutoGen.c so all constructors are executed.
Ard Biesheuvel [Tue, 21 Nov 2017 16:02:14 +0000 (16:02 +0000)]
BaseTools/tools_def AARCH64 ARM: suppres PIE sections via linker script
Recent distro builds of GCC 6 enable PIE linking by default, and allow
the previous behavior to be restored by passing the -no-pie command line
argument. Support for this was implemented by commits 1894a7c64c0a and 3380a591232d but unfortunately, it turns out that GCC 5 does not support
this command line argument, and exits with an error.
To avoid the need for yet another toolchain tag, to distinguish between
GCC 5 and GCC 6, let's use our GCC linker scripts when building objects
from .aslc files. This will ensure that the extra sections that are added
by the PIE linker are discarded from the ELF binary, and so they will not
corrupt the resulting .acpi file.
This reverts
1894a7c64c0a BaseTools/tools_def AARCH64 ARM: disable PIE linking 3380a591232d BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Leo Duran [Tue, 31 Oct 2017 17:54:52 +0000 (01:54 +0800)]
PcAtChipsetPkg: Define FixePCD's for RTC register values
Define FixedPCD's to replace macros in RTC driver, to allow
for platform-specific configurations.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Done:
if (EFI_ERROR (Status)) {
if (PciIo != NULL && Enabled) {
PciIo->Attributes (
PciIo,
EfiPciIoAttributeOperationSet,
OriginalAttributes,
NULL
);
}
}
In above codes, VS2012/VS2010 will report that "OriginalAttributes"
will be used without initialization. But in fact, when the if expression
is true(if (PciIo != NULL && Enabled)), the "OriginalAttributes" must be
initialized. In order to fix this false positive issue, we initialize the
"OriginalAttributes" after declaration.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Star Zeng [Mon, 20 Nov 2017 07:44:24 +0000 (15:44 +0800)]
MdeModulePkg EhciPei: Minor refinement about IOMMU
This patch is following 2c656af04d7f.
1. Fix typo "XHC" to "EHC".
2. Reinitialize Request(Phy/Map) and Data(Phy/Map)
in Urb, otherwise the last time value of them may
be used in error handling when error happens.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
We met some compatibility issues when doing Windows S4 resume.
Reverting the BME disabling patches to fix the S4 resume issue.
Signed-off-by: Ruiyu Ni <Ruiyu.ni@intel.com> Signed-off-by: Michael Turner <michael.turner@microsoft.com> Cc: Michael D Kinney <Michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
We met some compatibility issues when doing Windows S4 resume.
Reverting the BME disabling patches to fix the S4 resume issue.
Signed-off-by: Ruiyu Ni <Ruiyu.ni@intel.com> Signed-off-by: Michael Turner <michael.turner@microsoft.com> Cc: Michael D Kinney <Michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Ruiyu Ni [Mon, 20 Nov 2017 05:13:25 +0000 (13:13 +0800)]
MdeModulePkg/UefiBootManagerLib: Remove assertion
EfiBootManagerStartHotkeyService() asserts when "BootOptionSupport"
variable doesn't exist.
In fact, though "BootOptionSupport" variable is set in BdsDxe
module, it's possible that the variable is deleted by
PlatformBootManagerBeforeConsole().
The patch removes the assertion and adds code to handle the case.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
If a USB Mass Storage device does not support the Get
Max LUN command, then the USB I/O Protocol ControlTransfer()
service may return an error. If an error is returned for
this command, then assume that the device does not support
multiple LUNs and return a maximum LUN value of 0.
The USB Mass Storage Class Specification states that a
maximum LUN value larger than 0x0F is invalid. Add
a check to make sure this maximum LUN value is in this
valid range, and if it is not, then assume that the
device does not support multiple LUNs and return a
maximum LUN value of 0.
This change improves compatibility with USB FLASH drives
that do not support the Get Max LUN command or return
an invalid maximum LUN value.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
The USB I/O Protocol function ControlTransfer() has a DataLength
parameter that specifies the size of the Data buffer. The
UsbBusDxe module implements the USB I/O Protocol using the
services of the USB2 Host Controller Protocol. The DataLength
parameter in the USB2 Host Controller Protocol ControlTransfer()
service is an IN OUT parameter so the number of bytes actually
transferred is returned. Since the USB I/O Protocol
ControlTransfer() service can not return the number of bytes
actually transferred, the only option if the number of bytes
actually transferred is less than the number of bytes requested
is to return EFI_DEVICE_ERROR.
The change fixes an issue with a USB mass storage device that
responds with 0 bytes to the Get MAX LUN command.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Yonghong Zhu [Fri, 17 Nov 2017 03:29:19 +0000 (11:29 +0800)]
BaseTools: Fix a bug for single module build with GenC/GenMake option
when build a single module with GenC/GenMake option, currently it will
direct return after create Autogen code files, then it cause MaList is
empty, which cause an incorrect error message is reported.
The Visual Studio older than 2015 doesn't support constant integer
in binary format (0bxxx). This patch changes them to BIT macro to
fix it. This patch also cleans up coding style about unmatched
comment for return value.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Bi Dandan <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
This issue is caused by assigning incorrect value to PoolHdr.Size
if the requested size is more than MAX_POOL_SIZE, because the SMM
core will actually allocate page memory instead of pool memory in
this situation.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Wu Hao <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Wu Hao <hao.a.wu@intel.com> Tested-by: Wu Hao <hao.a.wu@intel.com>
Yonghong Zhu [Mon, 13 Nov 2017 07:24:17 +0000 (15:24 +0800)]
BaseTools: Fix the bug to collect source files per build rule family
when collect source files list we should also consider build rule
family. BuildRuleFamily may be set to the different one. It will
impact BuildRule and source files in INF file.
Hao Wu [Tue, 14 Nov 2017 03:33:10 +0000 (11:33 +0800)]
MdeModulePkg/UdfDxe: Avoid possible loss track of allocated buffer
In function FindFileEntry():
Instead of using the function parameter 'FileEntry', use a local
variable to store the buffer allocated for disk read operation.
For the below calling stack:
UdfOpenVolume() -> FindRootDirectory() -> FindFileEntry()
In FindFileEntry(), the call to 'DiskIo->ReadDisk()' is possible (e.g.
media change for a CD/DVD ROM device) to trigger a re-install of the
BlockIO(2) protocol which will further lead to a call of the BindingStop()
& BingdingStart() of the UdfDxe driver.
Meanwhile, for the above listed calling stack, the '**FileEntry'
parameter passed into FindFileEntry() is '&PrivFsData->Root'. 'PrivFsData'
is a driver-managed private data, it will be freed in BindingStop() and
re-allocate in BingdingStart().
In such case, if '*FileEntry' is used to store the allocated buffer, the
information will be lost if 'DiskIo->ReadDisk()' triggers a re-install of
the BlockIO(2) protocol. The subsequent call of the FreePool API:
FreePool (*FileEntry);
will cause issues.
This commit uses a local variable to store the allocated buffer.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Hao Wu [Fri, 13 Oct 2017 07:14:51 +0000 (15:14 +0800)]
MdeModulePkg/PartitionDxe: Merge the discovery of ElTorito into UDF
In order to create all of the children (El Torito standard and UDF) for
a CD/DVD media in an entry of the PartitionDriverBindingStart(), this
commit merges the discovery of the El Torito feature
(PartitionInstallElToritoChildHandles) into function
PartitionInstallUdfChildHandles.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Remove dependencies on gArmTokenSpaceGuid.PcdSystemMemoryBase and
gArmTokenSpaceGuid.PcdSystemMemorySize, the presence of which in
a [FixedPcd] section makes this module unusable for ArmVirtQemu.
Update the Request Sense check for the Request Sense Key of
USB_BOOT_SENSE_UNIT_ATTENTION. For this Sense Key, the
Additional Sense Key to EFI_STATUS mappings are:
A USB flash drive is returning Request Sense Key of
USB_BOOT_SENSE_UNIT_ATTENTION and an Additional Sense Key of
USB_BOOT_ASC_NO_MEDIA for a few seconds before returning an
Additional Sense Key of USB_BOOT_ASC_MEDIA_CHANGE.
The current logic treats this initial Request Sense info as an
error and reties the command 5 times before failing completely.
With this change the USB Flash Drive works correctly.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Paolo Bonzini [Thu, 16 Nov 2017 20:31:00 +0000 (21:31 +0100)]
OvmfPkg: save on I/O port accesses when the debug port is not in use
When SEV is enabled, every debug message printed by OVMF to the
QEMU debug port traps from the guest to QEMU character by character
because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore,
when OVMF is built with the DEBUG_VERBOSE bit (value 0x00400000)
enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the
OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib
library instance that is built into it, produce a huge amount of
log messages. Therefore, in SEV guests, the boot time impact is huge
(about 45 seconds _additional_ time spent writing to the debug port).
While these messages are very useful for analyzing guest behavior,
most of the time the user won't be capturing the OVMF debug log.
In fact libvirt does not provide a method for configuring log capture;
users that wish to do this (or are instructed to do this) have to resort
to <qemu:arg>.
The debug console device provides a handy detection mechanism; when read,
it returns 0xE9 (which is very much unlike the 0xFF that is returned by
an unused port). Use it to skip the possibly expensive OUT instructions
when the debug I/O port isn't plugged anywhere.
For SEC, the debug port has to be read before each full message.
However:
- if the debug port is available, then reading one byte before writing
a full message isn't tragic, especially because SEC doesn't print many
messages
- if the debug port is not available, then reading one byte instead of
writing a full message is still a win.
Paolo Bonzini [Thu, 16 Nov 2017 20:30:59 +0000 (21:30 +0100)]
OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC
The next patch will want to add a global variable to
PlatformDebugLibIoPort, but this is not suitable for the SEC
phase, because SEC runs from read-only flash. The solution is
to have two library instances, one for SEC and another
for all other firmware phases. This patch adds the "plumbing"
for the SEC library instance, separating the INF files and
moving the constructor to a separate C source file.
Laszlo Ersek [Tue, 24 Oct 2017 15:21:25 +0000 (17:21 +0200)]
OvmfPkg: restore temporary SEC/PEI RAM size to 64KB
(1) In the PEI phase, the PCD database is maintained in a GUID HOB. In
OVMF, we load the PCD PEIM before any other PEIMs (using APRIORI PEI),
so that all other PEIMs can use dynamic PCDs. Consequently,
- the PCD GUID HOB is initially allocated from the temporary SEC/PEI
heap,
- whenever we introduce a dynamic PCD to a PEIM built into OVMF such
that the PCD is new to OVMF's whole PEI phase, the PCD GUID HOB (and
its temporary heap footprint) grow.
I've noticed that, if we add just one more dynamic PCD to the PEI
phase, then in the X64 build,
- we get very close to the half of the temporary heap (i.e., 8192
bytes),
- obscure PEI phase hangs or DXE core initialization failures
(ASSERTs) occur. The symptoms vary between the FD_SIZE_2MB and
FD_SIZE_4MB builds of X64 OVMF.
(2) I've found that commit
2bbd7e2fbd4b ("UefiCpuPkg/MtrrLib: Update algorithm to calculate
optimal settings", 2017-09-27)
introduced a large (16KB) stack allocation:
> The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and
> MtrrSetMemoryAttribute() to use the 4-page stack buffer for calculation.
> ...
> +#define SCRATCH_BUFFER_SIZE (4 * SIZE_4KB)
> ...
> @@ -2207,17 +2462,66 @@ MtrrSetMemoryAttributeInMtrrSettings (
> ...
> + UINT8 Scratch[SCRATCH_BUFFER_SIZE];
(3) OVMF's temp SEC/PEI RAM size has been 32KB ever since commit
7cb6b0e06809 ("OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to
0x810000", 2014-01-21)
Of that, the upper 16KB half is stack (growing down), and the lower
16KB half is heap.
Thus, OvmfPkg/PlatformPei's calls to "UefiCpuPkg/Library/MtrrLib", in
QemuInitializeRam(), cause the Scratch array to overflow the entire
stack (heading towards lower addresses), and corrupt the heap below
the stack. It turns out that the total stack demand is about 24KB, so
the overflow is able to corrupt the upper 8KB of the heap. If that
part of the heap is actually used (for example because we grow the PCD
GUID HOB sufficiently), mayhem ensues.
(4) Right after commit 7cb6b0e06809 (see above), there would be no room
left above the 32KB temp SEC/PEI RAM. However, given more recent
commits
45d870815156 ("OvmfPkg/PlatformPei: rebase and resize the permanent
PEI memory for S3", 2016-07-13)
we can now restore the temp SEC/PEI RAM size to the original
(pre-7cb6b0e06809) 64KB. This will allow for a 32KB temp SEC/PEI
stack, which accommodates the ~24KB demand mentioned in (3).
(Prior patches in this series will let us monitor the stack usage in
the future.)
Laszlo Ersek [Wed, 8 Nov 2017 19:32:30 +0000 (20:32 +0100)]
OvmfPkg/Sec/X64: seed the temporary RAM with PcdInitValueInTempStack
This allows the PEI core to report the maximum temporary SEC/PEI stack
usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function
[MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]:
I unit-tested this change by transitorily adding an infinite loop right
after the "rep stosq", and dumping the guest's temp SEC/PEI RAM (32KB
currently) while the guest was stuck in the loop. The dump includes one
dword from before and after the temp SEC/PEI RAM:
Laszlo Ersek [Wed, 8 Nov 2017 18:43:21 +0000 (19:43 +0100)]
OvmfPkg/Sec/Ia32: seed the temporary RAM with PcdInitValueInTempStack
This allows the PEI core to report the maximum temporary SEC/PEI stack
usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function
[MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]:
I unit-tested this change by transitorily adding an infinite loop right
after the "rep stosd", and dumping the guest's temp SEC/PEI RAM (32KB
currently) while the guest was stuck in the loop. The dump includes one
dword from before and after the temp SEC/PEI RAM:
"Main.asm" calls TransitionFromReal16To32BitFlat (and does some other
things) before it jumps to the platform's SEC entry point.
TransitionFromReal16To32BitFlat enters big real mode, and sets the DS, ES,
FS, GS, and SS registers to offset ("selector") LINEAR_SEL in the GDT
(defined in "UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm"). The
GDT entry ("segment descriptor") at LINEAR_SEL defines a segment covering
the full 32-bit address space, meant for "read/write data".
Document this fact for all the affected segment registers, as output
parameters for TransitionFromReal16To32BitFlat, saying "Selector allowing
flat access to all addresses".
For 64-bit SEC, "Main.asm" calls Transition32FlatTo64Flat in addition,
between calling TransitionFromReal16To32BitFlat and jumping to the SEC
entry point. Transition32FlatTo64Flat enters long mode. In long mode,
segmentation is largely ignored:
- all segments are considered flat (covering the whole 64-bit address
space),
- with the (possible) exception of FS and GS, whose bases can still be
changed, albeit with new methods, not through the GDT. (Through the
IA32_FS_BASE and IA32_GS_BASE Model Specific Registers, and/or the
WRFSBASE, WRGSBASE and SWAPGS instructions.)
Thus, document the segment registers with the same "Selector allowing flat
access to all addresses" language on the "Main.asm" level too, since that
is valid for both 32-bit and 64-bit modes.
(Technically, "Main.asm" does not return, but RBP/EBP, passed similarly to
the SEC entry point, is already documented as an output parameter.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Eric Dong <eric.dong@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
projects / mirror_edk2.git / log