Jian J Wang [Thu, 15 Mar 2018 04:43:20 +0000 (12:43 +0800)]
MdeModulePkg/PiSmmCore: fix bits operation error on a boundary condition
If given address is on 64K boundary and the requested bit number is 64,
all SetBits(), ClearBits() and GetBits() will encounter ASSERT problem
in trying to do a 64 bits of shift, which is not allowed by LShift() and
RShift(). This patch tries to fix this issue by turning bits operation
into whole integer operation in such situation.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Jian J Wang [Wed, 14 Mar 2018 08:28:34 +0000 (16:28 +0800)]
MdeModulePkg/Core: allow HeapGuard even before CpuArchProtocol installed
Due to the fact that HeapGuard needs CpuArchProtocol to update page
attributes, the feature is normally enabled after CpuArchProtocol is
installed. Since there're some drivers are loaded before CpuArchProtocl,
they cannot make use HeapGuard feature to detect potential issues.
This patch fixes above situation by updating the DXE core to skip the
NULL check against global gCpu in the IsMemoryTypeToGuard(), and adding
NULL check against gCpu in SetGuardPage() and UnsetGuardPage() to make
sure that they can be called but do nothing. This will allow HeapGuard to
record all guarded memory without setting the related Guard pages to not-
present.
Once the CpuArchProtocol is installed, a protocol notify will be called
to complete the work of setting Guard pages to not-present.
Please note that above changes will cause a #PF in GCD code during cleanup
of map entries, which is initiated by CpuDxe driver to update real mtrr
and paging attributes back to GCD. During that time, CpuDxe doesn't allow
GCD to update memory attributes and then any Guard page cannot be unset.
As a result, this will prevent Guarded memory from freeing during memory
map cleanup.
The solution is to avoid allocating guarded memory as memory map entries
in GCD code. It's done by setting global mOnGuarding to TRUE before memory
allocation and setting it back to FALSE afterwards in GCD function
CoreAllocateGcdMapEntry().
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Jiewen Yao [Wed, 14 Mar 2018 13:47:19 +0000 (21:47 +0800)]
QuarkPlatformPkg: remove TrEE reference.
TrEE is deprecated. We need use Tcg2.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Kelly Steele <kelly.steele@intel.com> Cc: Chao B Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com> Reviewed-by: Kelly Steele <kelly.steele@intel.com>
Heyi Guo [Thu, 8 Feb 2018 03:13:27 +0000 (11:13 +0800)]
MdeModulePkg/PciBus: return CPU address for GetBarAttributes
According to UEFI spec 2.7, PciIo->GetBarAttributes should return host
address (CPU view ddress) rather than device address (PCI view
address), and
device address = host address + address translation offset,
so we subtract translation from device address before returning.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Signed-off-by: Yi Li <phoenix.liyi@huawei.com> Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Heyi Guo [Thu, 8 Feb 2018 03:13:27 +0000 (11:13 +0800)]
MdeModulePkg/PciBus: convert host address to device address
According to UEFI spec 2.7, PciRootBridgeIo->Configuration() should
return host address (CPU view ddress) rather than device address
(PCI view address), so in function GetMmioAddressTranslationOffset we
need to convert the range to device address before comparing.
And device address = host address + translation offset.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Signed-off-by: Yi Li <phoenix.liyi@huawei.com> Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Heyi Guo [Thu, 8 Feb 2018 03:13:26 +0000 (11:13 +0800)]
MdeModulePkg/PciHostBridgeDxe: Add support for address translation
PCI address translation is necessary for some non-x86 platforms. On
such platforms, address value (denoted as "device address" or "address
in PCI view") set to PCI BAR registers in configuration space might be
different from the address which is used by CPU to access the
registers in memory BAR or IO BAR spaces (denoted as "host address" or
"address in CPU view"). The difference between the two addresses is
called "Address Translation Offset" or simply "translation", and can
be represented by "Address Translation Offset" in ACPI QWORD Address
Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
definitions of QWORD Address Space Descriptor, and we will follow UEFI
definition on UEFI protocols, such as PCI root bridge IO protocol and
PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
to apply to the Starting address to convert it to a PCI address". This
means:
1. Translation = device address - host address.
2. PciRootBridgeIo->Configuration should return CPU view address, as
well as PciIo->GetBarAttributes.
Summary of addresses used in protocol interfaces and internal
implementations:
1. *Only* the following protocol interfaces assume Address is Device
Address:
(1). PciHostBridgeResourceAllocation.GetProposedResources()
Otherwise PCI bus driver cannot set correct address into PCI
BARs.
(2). PciRootBridgeIo.Mem.Read() and PciRootBridgeIo.Mem.Write()
(3). PciRootBridgeIo.CopyMem()
UEFI and PI spec have clear statements for all other protocol
interfaces about the address type.
2. Library interfaces and internal implementation:
(1). Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address.
It is easy to check whether the address is below 4G or above 4G.
(2). Addresses in PCI_ROOT_BRIDGE_INSTANCE.ResAllocNode are host
address, for they are allocated from GCD.
(3). Address passed to PciHostBridgeResourceConflict is host address,
for it comes from PCI_ROOT_BRIDGE_INSTANCE.ResAllocNode.
RESTRICTION: to simplify the situation, we require the alignment of
Translation must be larger than any BAR alignment in the same root
bridge, so that resource allocation alignment can be applied to both
device address and host address.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Signed-off-by: Yi Li <phoenix.liyi@huawei.com> Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Add Translation field to PCI_ROOT_BRIDGE_APERTURE. Translation is used
to represent the difference between device address and host address,
if they are not the same on some platforms.
In UEFI 2.7, "Address Translation Offset" is "Offset to apply to the
Starting address to convert it to a PCI address". This means:
Translation = device address - host address
So we also use the above calculation for this Translation field to
keep consistent.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Signed-off-by: Yi Li <phoenix.liyi@huawei.com> Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Heyi Guo [Wed, 28 Feb 2018 02:19:28 +0000 (10:19 +0800)]
OvmfPkg/PciHostBridgeLib: clear PCI aperture vars for (re)init
Use ZeroMem() to initialize (or re-initialize) all fields in temporary
PCI_ROOT_BRIDGE_APERTURE variables to zero. This is not mandatory but
is helpful for future extension: when we add new fields to
PCI_ROOT_BRIDGE_APERTURE and the default value of these fields can
safely be zero, this code will not suffer from an additional
change.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Signed-off-by: Yi Li <phoenix.liyi@huawei.com> Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Heyi Guo [Wed, 28 Feb 2018 02:19:28 +0000 (10:19 +0800)]
CorebootPayloadPkg/PciHostBridgeLib: clear aperture vars for (re)init
Use ZeroMem() to initialize (or re-initialize) all fields in temporary
PCI_ROOT_BRIDGE_APERTURE variables to zero. This is not mandatory but
helpful for future extension: when we add new fields to
PCI_ROOT_BRIDGE_APERTURE and the default value of these fields can
safely be zero, this code will not suffer from an additional change.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Signed-off-by: Yi Li <phoenix.liyi@huawei.com> Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com> Reviewed-by: Benjamin You <benjamin.you@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Heyi Guo [Thu, 15 Mar 2018 07:17:43 +0000 (15:17 +0800)]
ArmPkg/TimerDxe: Add ISB for timer compare value reload
If timer interrupt is level sensitive, reloading timer compare
register has a side effect of clearing GIC pending status, so a "ISB"
is needed to make sure this instruction is executed before enabling
CPU IRQ, or else we may get spurious timer interrupts.
Star Zeng [Wed, 14 Mar 2018 09:12:22 +0000 (17:12 +0800)]
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU
de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases.
1. For the case that the USB3 debug port instance and DMA buffers are
from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers
by AllocateAddress with the memory type accessible by SMM environment.
But reallocating the DMA buffers by AllocateAddress may fail.
2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from
S3Resume2Pei, HOB is still needed to be used for DMA operation, but
PiSmmCpuDxeSmm has no way to get the HOB at S3 resume.
The patch is to re-support IOMMU.
For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI
notification to reinitialize hardware with granted DMA buffer if IOMMU
PPI is not present yet.
For DXE, map DMA buffer by PciIo in PciIo notification for early DXE,
and register DxeSmmReadyToLock notification to reinitialize hardware
with granted DXE DMA buffer accessible by SMM environment for late DXE.
DebugAgentLib has been managing the instance as Handle in
HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used
directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3
could get consistent Handle(instance) from DebugAgentLib.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Fix GCC build failures below.
variable 'EvtTrb' set but not used [-Werror=unused-but-set-variable]
variable 'Index' set but not used [-Werror=unused-but-set-variable]
The build failure could only be caught with -D SOURCE_DEBUG_USE_USB3
build flag.
This leads to bad performance, when many devices exist such that the
firmware can drive them, but they aren't marked for booting in the
"bootorder" fw_cfg file. Namely,
(1) EfiBootManagerConnectAll() talks to all hardware, which takes long.
Plus some DriverBindingStart() functions write NV variables, which is
also slow. (For example, the IP config policy for each NIC is stored
in an NV var that is named after the MAC).
(2) EfiBootManagerRefreshAllBootOption() generates boot options from the
protocol instances produced by (1). Writing boot options is slow.
(3) Under the above circumstances, SetBootOrderFromQemu() removes most of
the boot options produced by (2). Erasing boot options is slow.
Introduce ConnectDevicesFromQemu() as a replacement for (1): only connect
devices that the QEMU user actually wants to boot off of.
(There's a slight loss of compatibility when a platform switches from
EfiBootManagerConnectAll() to ConnectDevicesFromQemu().
EfiBootManagerConnectAll() may produce UEFI device paths that are unknown
to QemuBootOrderLib (that is, for neither PCI- nor virtio-mmio-based
devices). The BootOrderComplete() function lets such unmatched boot
options survive at the end of the boot order. With
ConnectDevicesFromQemu(), these options will not be auto-generated in the
first place. They may still be produced by other means.
SetBootOrderFromQemu() is not modified in any way; reordering+filtering
boot options remains a separate task.)
Laszlo Ersek [Tue, 13 Mar 2018 14:55:12 +0000 (15:55 +0100)]
OvmfPkg/QemuBootOrderLib: clean up translation of virtio-net over MMIO
The "/MAC(" suffix of the translated UEFI devpath prefix is unnecessary
for matching, because the virtio-mmio base address in VenHwString is
unique anyway. Furthermore, the partial string "MAC(" cannot be processed
by ConvertTextToDevicePath(), which will become relevant later in this
series. Remove "/MAC(".
Jian J Wang [Tue, 13 Mar 2018 02:08:24 +0000 (10:08 +0800)]
MdeModulePkg/Core: fix mem alloc issues in heap guard
There're two ASSERT issues which will be triggered by boot loader of
Windows 10.
The first is caused by allocating memory in heap guard during another
memory allocation, which is not allowed in DXE core. Avoiding reentry
of memory allocation has been considered in heap guard feature. But
there's a hole in the code of function FindGuardedMemoryMap(). The fix
is adding AllocMapUnit parameter in the condition of while(), which
will prevent memory allocation from happenning during Guard page
check operation.
The second is caused by the core trying to allocate page 0 with Guard
page, which will cause the start address rolling back to the end of
supported system address. According to the requirement of heap guard,
the fix is just simply skipping the free memory at page 0 and let
the core continue searching free memory after it.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Ruiyu Ni [Tue, 13 Mar 2018 07:39:47 +0000 (15:39 +0800)]
ShellPkg/[hex]edit: Fix mouse freeze issue
In edit or hexedit, the mouse cursor doesn't move when moving
the mouse.
The root cause is 5563281fa2b31093a1cbd415553b9264c5136e89
* ShellPkg/[hex]edit: use SimpleTextInEx to read console
wrongly uses WaitForEvent() to listen keyboard input.
It blocks the code execution when there is no keyboard input.
While the same function also polls the mouse move status,
the mouse movement cannot be reflected to the screen when
there is no keyboard input.
The patch fixes the issue by use CheckEvent() instead of
WaitForEvent().
Laszlo Ersek [Sat, 10 Mar 2018 23:25:54 +0000 (00:25 +0100)]
OvmfPkg/XenPvBlkDxe: list "DriverBinding.h" in the INF file
The header file provides (extern) declarations for the
EFI_DRIVER_BINDING_PROTOCOL member functions that are defined in
"XenPvBlkDxe.c". This way "gXenPvBlkDxeDriverBinding" can be initialized
near the top of "XenPvBlkDxe.c", ahead of the member function definitions.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 20:51:48 +0000 (21:51 +0100)]
OvmfPkg/VirtioPciDeviceDxe: list "VirtioPciDevice.h" in the INF file
Among other things, the header file declares the functions that implement
the VIRTIO_DEVICE_PROTOCOL members over virtio-pci (v0.9.5). The functions
are defined in "VirtioPciFunctions.c", and referenced in the
initialization of "mDeviceProtocolTemplate", in "VirtioPciDevice.c".
Laszlo Ersek [Sat, 10 Mar 2018 23:05:59 +0000 (00:05 +0100)]
OvmfPkg/VirtioNetDxe: list "VirtioNet.h" in the INF file
The header file declares several functions and global variables that are
shared between various translation units in this module. The header file
also defines macros and types that are private to the driver.
Laszlo Ersek [Sat, 10 Mar 2018 22:42:16 +0000 (23:42 +0100)]
OvmfPkg/QemuVideoDxe: list "VbeShim.h" in the INF file
The header file is manually generated with "VbeShim.sh" (from the IA32
assembly code in "VbeShim.asm"), to be included by "VbeShim.c".
"VbeShim.c" is linked into the driver only for the IA32 and X64
architectures: while the InstallVbeShim() function that "VbeShim.c"
defines is declared commonly in "Qemu.h", the call in the also common
"Driver.c" source file depends on the MDE_CPU_IA32 / MDE_CPU_X64
preprocessor macros.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Phil Dennis-Jordan <phil@philjordan.eu> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 22:32:12 +0000 (23:32 +0100)]
OvmfPkg/QemuVideoDxe: list "UnalignedIoInternal.h" in the INF file
The header file declares the UnalignedIoWrite32() and UnalignedIoRead32()
functions. The functions are called from VmwareSvgaWrite() and
VmwareSvgaRead() in the common "Driver.c" source file. The
UnalignedIo*32() functions are defined with inline assembly, C-language
compiler intrinsics, or as ASSERT(FALSE), in distinct C files, dependent
on architecture and toolchain.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Phil Dennis-Jordan <phil@philjordan.eu> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 22:26:12 +0000 (23:26 +0100)]
OvmfPkg/QemuVideoDxe: list "Qemu.h" in the INF file
Among many other things, "Qemu.h" declares the
QemuVideoGraphicsOutputConstructor() and
QemuVideoGraphicsOutputDestructor() functions, which are defined in
"Gop.c", and called from "Driver.c".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Phil Dennis-Jordan <phil@philjordan.eu> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 22:14:30 +0000 (23:14 +0100)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "QemuFlash.h" in INF files
Among other things, the header file declares functions that are called
from the FVB protocol member functions in "FwBlockService.c", and defined
in "QemuFlash.c".
Both C files are listed in both "FvbServicesSmm.inf" and
"FvbServicesRuntimeDxe.inf", thus add the header file to both INF files as
well.
Laszlo Ersek [Sat, 10 Mar 2018 22:02:32 +0000 (23:02 +0100)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "FwBlockService.h" in INFs
Among other things, the header file provides (extern) declarations for the
EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL member functions that are defined in
"FwBlockService.c". This way "mFvbDeviceTemplate.FwVolBlockInstance" can
be initialized near the top of "FwBlockService.c", ahead of the member
function definitions.
"FwBlockService.c" is linked into both the DXE_SMM_DRIVER and the
DXE_RUNTIME_DRIVER builds of this module, thus list the header file in
both INF files.
Laszlo Ersek [Sat, 10 Mar 2018 21:06:34 +0000 (22:06 +0100)]
OvmfPkg/PlatformDxe: list "PlatformConfig.h" in the INF file
The header file declares the PlatformConfigSave() and PlatformConfigLoad()
functions (and defines related types and macros). The functions are
defined in "PlatformConfig.c" and called from "Platform.c".
Laszlo Ersek [Sat, 10 Mar 2018 21:06:34 +0000 (22:06 +0100)]
OvmfPkg/PlatformDxe: list "Platform.h" in the INF file
The header file defines HII-related macros and types that are shared
between the form description in "PlatformForms.vfr" and the HII driver
logic "Platform.c".
Laszlo Ersek [Sat, 10 Mar 2018 20:58:44 +0000 (21:58 +0100)]
OvmfPkg/VirtioMmioDeviceLib: improve style of mMmioDeviceProtocolTemplate
In edk2, we spell "static" "STATIC", plus objects with static storage
duration (esp. protocol templates) should be const-qualified (spelled
"CONST") whenever possible.
Laszlo Ersek [Sat, 10 Mar 2018 20:51:48 +0000 (21:51 +0100)]
OvmfPkg/VirtioMmioDeviceLib: list "VirtioMmioDevice.h" in the INF file
Among other things, the header file declares the functions that implement
the VIRTIO_DEVICE_PROTOCOL members over virtio-mmio. The functions are
defined in "VirtioMmioDeviceFunctions.c", and referenced in the
initialization of "mMmioDeviceProtocolTemplate", in "VirtioMmioDevice.c".
Laszlo Ersek [Sat, 10 Mar 2018 20:41:36 +0000 (21:41 +0100)]
OvmfPkg/QemuBootOrderLib: list "ExtraRootBusMap.h" in the INF file
The header file declares the CreateExtraRootBusMap(),
DestroyExtraRootBusMap(), and MapRootBusPosToBusNr() functions. They are
defined in "ExtraRootBusMap.c", and called from "QemuBootOrderLib.c".
Laszlo Ersek [Sat, 10 Mar 2018 20:14:06 +0000 (21:14 +0100)]
OvmfPkg/PlatformDebugLibIoPort: list "DebugLibDetect.h" in the INF files
Among other things, "DebugLibDetect.h" declares the
PlatformDebugLibIoPortFound() function. The function is called from
"DebugLib.c", which is included in both library instances. The function is
defined separately per library instance, in "DebugLibDetectRom.c" and
"DebugLibDetect.c", respectively.
Laszlo Ersek [Sat, 10 Mar 2018 19:49:56 +0000 (20:49 +0100)]
OvmfPkg/LockBoxLib: list "LockBoxLib.h" in the INF files
Among other things, the header file declares the AllocateAcpiNvsPool()
function. This function is called from the "LockBoxLib.c" source file (in
the implementation of the SaveLockBox() library API), which is built into
both library instances. AllocateAcpiNvsPool() is implemented separately
per library instance, in "LockBoxBase.c" and "LockBoxDxe.c", respectively.
(In the LockBoxBaseLib instance, the AllocateAcpiNvsPool() function is
never expected to be called -- the public SaveLockBox() API should never
be called before the DXE phase --, we just have to provide a stub for
linking purposes.)
Laszlo Ersek [Sat, 10 Mar 2018 19:43:36 +0000 (20:43 +0100)]
OvmfPkg/LoadLinuxLib: list "LoadLinuxLib.h" in the INF file
The header file declares the InitLinuxDescriptorTables() and
SetLinuxDescriptorTables() functions, which are called from "Linux.c" and
implemented in "LinuxGdt.c".
The header file also declares the JumpToKernel() and JumpToUefiKernel()
functions, which are similarly called from "Linux.c". They are implemented
(dependent on architecture) in "Ia32/JumpToKernel.nasm" and
"X64/JumpToKernel.nasm".
Laszlo Ersek [Sat, 10 Mar 2018 19:20:14 +0000 (20:20 +0100)]
OvmfPkg/BaseMemEncryptSevLib: list "X64/VirtualMemory.h" in the INF file
Among other things, the header file declares the
InternalMemEncryptSevSetMemoryDecrypted() and
InternalMemEncryptSevSetMemoryEncrypted() functions. The functions are
called from "X64/MemEncryptSevLib.c", and defined in
"X64/VirtualMemory.c".
Laszlo Ersek [Sat, 10 Mar 2018 19:20:14 +0000 (20:20 +0100)]
OvmfPkg/AcpiTimerLib: list "AcpiTimerLib.h" in the INF files
The header file declares the InternalAcpiGetTimerTick() function. The
function is called from "AcpiTimerLib.c", which is built into all three
library instances. The function is defined individually per library
instance, in "BaseRomAcpiTimerLib.c", "BaseAcpiTimerLib.c", and
"DxeAcpiTimerLib.c" (enumerated in increasing firmware phase order).
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/EmuVariableFvbRuntimeDxe: list "Fvb.h" in the INF file
Among other things, the header file provides (extern) declarations for the
EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL member functions that are defined in
"Fvb.c". This way "mEmuVarsFvb.FwVolBlockInstance" can be initialized near
the top of "Fvb.c", ahead of the member function definitions.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "LegacyRegion.h" in the INF file
Among other things, the header file provides (extern) declarations for the
EFI_LEGACY_REGION2_PROTOCOL member functions that are defined in
"LegacyRegion.c". This way "mLegacyRegion2" can be initialized near the
top of "LegacyRegion.c", ahead of the member function definitions.
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "LegacyInterrupt.h" in the INF file
Among other things, the header file provides (extern) declarations for the
EFI_LEGACY_INTERRUPT_PROTOCOL member functions that are defined in
"LegacyInterrupt.c". This way "mLegacyInterrupt" can be initialized near
the top of "LegacyInterrupt.c", ahead of the member function definitions.
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "CsmSupportLib.h" in the INF file
The header file declares the functions LegacyRegionInit(),
LegacyInterruptInstall() and LegacyBiosPlatformInstall(). They are defined
in "LegacyRegion.c", "LegacyInterrupt.c", and "LegacyPlatform.c",
respectively, and are all called from CsmSupportLibConstructor() in
"CsmSupportLib.c".
Laszlo Ersek [Sat, 10 Mar 2018 18:42:15 +0000 (19:42 +0100)]
OvmfPkg/BlockMmioToBlockIoDxe: list "BlockIo.h" in the INF file
Among other things, the header file declares the
"gBlockMmioToBlockIoComponentName" and "gBlockMmioToBlockIoComponentName2"
protocol instance structures. They are defined and initialized in
"ComponentName.c" and installed in "BlockIo.c".
Laszlo Ersek [Sat, 10 Mar 2018 18:16:02 +0000 (19:16 +0100)]
OvmfPkg/AcpiPlatformDxe: list "QemuLoader.h" in the INF files
"QemuLoader.h" defines the command structures of QEMU's ACPI
linker/loader. The client code is in "QemuFwCfgAcpi.c", which is part of
both builds of this driver.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Phil Dennis-Jordan <phil@philjordan.eu> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 17:26:36 +0000 (18:26 +0100)]
OvmfPkg/AcpiPlatformDxe: don't #include "QemuLoader.h" in "Qemu.c"
We added initial support for QEMU's ACPI linker/loader in commit a618eaa1f45d ("OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU
interface", 2014-06-19). This commit defined the command structures in the
new file "QemuLoader.h", and #included the header in the preexistent
"Qemu.c" file, where the initial command script processing loop was being
implemented.
In commit 14b0faadfc87 ("OvmfPkg/AcpiPlatformDxe: Split QEMU fw-cfg into a
new file", 2015-02-02), we extracted the -- by then, more advanced --
linker/loader script processing from "Qemu.c" to "QemuFwCfgAcpi.c".
"Qemu.c" was going to need "QemuLoader.h" no longer, but we forgot to make
the #include directive unique to the new "QemuFwCfgAcpi.c" file. Do it
now.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 17:13:18 +0000 (18:13 +0100)]
OvmfPkg/AcpiPlatformDxe: list "AcpiPlatform.h" in the INF files
Among other things, the header file declares InstallAcpiTables(). This
function is called from AcpiPlatformEntryPoint() -- the entry point of
both INF files, defined in the common "EntryPoint.c" file --, and it is
defined (dependent on INF file) in "AcpiPlatform.c" or
"QemuFwCfgAcpiPlatform.c".
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Phil Dennis-Jordan <phil@philjordan.eu> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 16:54:24 +0000 (17:54 +0100)]
ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: list "PrePi.h" in INF file
Among other things, the header file declares the ArchInitialize()
function, which is called from "PrePi.c", and implemented (dependent on
architecture) in "AArch64/ArchPrePi.c" and "Arm/ArchPrePi.c".
Jiaxin Wu [Mon, 12 Mar 2018 00:50:12 +0000 (08:50 +0800)]
NetworkPkg/IScsiDxe: Fix the ISCSI connection failure in certain case.
The ISCSI connection will fail for the first time if the target info is
retrieved from DHCP and expressed as URI format. The issue is caused by
the missing DNS protocol dependency check during the driver support
function.
This patch is to fix the above issue.
Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Jiaxin Wu [Mon, 12 Mar 2018 00:50:41 +0000 (08:50 +0800)]
MdeModulePkg/Mtftp4Dxe: Fix the incorrect return status.
The incorrect return status was caused by the commit of 39b0867d, which
was to resolve the token status error that does not compliance with spec
definition, but it results the protocol status not compliance with spec
definition.
This patch is to resolve above issue.
Cc: Wang Fan <fan.wang@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Wang, Fan <fan.wang@intel.com>
Brijesh Singh [Fri, 9 Mar 2018 16:06:03 +0000 (10:06 -0600)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active
Commit:24e4ad7 (OvmfPkg: Add AmdSevDxe driver) added a driver which runs
early in DXE phase and clears the C-bit from NonExistent entry -- which
is later split and accommodate the flash MMIO. When SMM is enabled, we
build two sets of page tables; first page table is used when executing
code in non SMM mode (SMM-less-pgtable) and second page table is used
when we are executing code in SMM mode (SMM-pgtable).
During boot time, AmdSevDxe driver clears the C-bit from the
SMM-less-pgtable. But when SMM is enabled, Qemu Flash services are used
from SMM mode.
In this patch we explicitly clear the C-bit from Qemu flash MMIO range
before we probe the flash. When OVMF is built with SMM_REQUIRE then
call to initialize the flash services happen after the SMM-pgtable is
created and processor has served the first SMI. At this time we will
have access to the SMM-pgtable.
The following order of operations ensures that 3rd party UEFI modules,
such as PCI option ROMs and other modules possibly loaded from outside
of firmware volumes, are measured into the TPM:
(1) Tcg2Dxe is included in DXEFV, therefore it produces the TCG2
protocol sometime in the DXE phase (assuming a TPM2 chip is present,
reported via PcdTpmInstanceGuid).
(2) The DXE core finds that no more drivers are left to dispatch from
DXEFV, and we enter the BDS phase.
(3) OVMF's PlatformBootManagerLib connects all PCI root bridges
non-recursively, producing PciIo instances and discovering PCI
oproms.
(4) The dispatching of images that don't originate from FVs is deferred
at this point, by
"MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c".
(6) OVMF's PlatformBootManagerLib calls
EfiBootManagerDispatchDeferredImages() -- the images deferred in
step (4) are now dispatched.
(7) Image dispatch invokes the Security / Security2 Arch protocols
(produced by SecurityStubDxe). In this patch, we hook
DxeTpm2MeasureBootLib into SecurityStubDxe, therefore image dispatch
will try to locate the TCG2 protocol, and measure the image into the
TPM2 chip with the protocol. Because of step (1), the TCG2 protocol
will always be found and used (assuming a TPM2 chip is present).
projects / mirror_edk2.git / log