]> git.proxmox.com Git - mirror_edk2.git/log
mirror_edk2.git
6 years agoSecurityPkg/Tpm2DeviceLibTrEE: remove TrEE.
Jiewen Yao [Wed, 14 Mar 2018 13:54:59 +0000 (21:54 +0800)]
SecurityPkg/Tpm2DeviceLibTrEE: remove TrEE.

TrEE is deprecated. We need use Tcg2.

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>
6 years agoSecurityPkg/TrEEConfig: remove TrEE.
Jiewen Yao [Wed, 14 Mar 2018 13:54:21 +0000 (21:54 +0800)]
SecurityPkg/TrEEConfig: remove TrEE.

TrEE is deprecated. We need use Tcg2.

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>
6 years agoSecurityPkg/TrEEPei: remove TrEE.
Jiewen Yao [Wed, 14 Mar 2018 13:53:48 +0000 (21:53 +0800)]
SecurityPkg/TrEEPei: remove TrEE.

TrEE is deprecated. We need use Tcg2.

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>
6 years agoSecurityPkg/TrEEDxe: remove TrEE.
Jiewen Yao [Wed, 14 Mar 2018 13:53:19 +0000 (21:53 +0800)]
SecurityPkg/TrEEDxe: remove TrEE.

TrEE is deprecated. We need use Tcg2.

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>
6 years agoSecurityPkg/TrEESmm: remove TrEE.
Jiewen Yao [Wed, 14 Mar 2018 13:52:47 +0000 (21:52 +0800)]
SecurityPkg/TrEESmm: remove TrEE.

TrEE is deprecated. We need use Tcg2.

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>
6 years agoSecurityPkg/dsc: remove TrEE.
Jiewen Yao [Wed, 14 Mar 2018 13:52:11 +0000 (21:52 +0800)]
SecurityPkg/dsc: remove TrEE.

TrEE is deprecated. We need use Tcg2.

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>
6 years agoVlv2TbltDevicePkg/dsc/fdf: use Tcg2 instead of TrEE.
Jiewen Yao [Wed, 14 Mar 2018 13:51:13 +0000 (21:51 +0800)]
Vlv2TbltDevicePkg/dsc/fdf: use Tcg2 instead of TrEE.

TrEE is deprecated. We need use Tcg2.

Cc: David Wei <david.wei@intel.com>
Cc: Mang Guo <mang.guo@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: Mang Guo <mang.guo@intel.com>
6 years agoVlv2TbltDevicePkg/Bds: use Tcg2 instead of TrEE.
Jiewen Yao [Wed, 14 Mar 2018 13:50:42 +0000 (21:50 +0800)]
Vlv2TbltDevicePkg/Bds: use Tcg2 instead of TrEE.

TrEE is deprecated. We need use Tcg2.

Cc: David Wei <david.wei@intel.com>
Cc: Mang Guo <mang.guo@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: Mang Guo <mang.guo@intel.com>
6 years agoVlv2TbltDevicePkg/Tcg2PhysicalPresenceLib: use Tcg2 instead of TrEE.
Jiewen Yao [Wed, 14 Mar 2018 13:49:52 +0000 (21:49 +0800)]
Vlv2TbltDevicePkg/Tcg2PhysicalPresenceLib: use Tcg2 instead of TrEE.

TrEE is deprecated. We need use Tcg2.

Cc: David Wei <david.wei@intel.com>
Cc: Mang Guo <mang.guo@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: Mang Guo <mang.guo@intel.com>
6 years agoQuarkPlatformPkg: remove TrEE reference.
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>
6 years agoShellPkg/UefiHandleParsingLib: remove TrEE reference.
Jiewen Yao [Wed, 14 Mar 2018 13:46:00 +0000 (21:46 +0800)]
ShellPkg/UefiHandleParsingLib: remove TrEE reference.

TrEE is deprecated. We need use Tcg2.

Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@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: Ruiyu Ni <ruiyu.ni@intel.com>
6 years agoMdeModulePkg/PciBus: return CPU address for GetBarAttributes
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>
6 years agoMdeModulePkg/PciBus: convert host address to device address
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>
6 years agoMdeModulePkg/PciHostBridgeDxe: Add support for address translation
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>
6 years agoMdeModulePkg/PciHostBridgeLib.h: add address Translation
Heyi Guo [Tue, 27 Feb 2018 11:53:34 +0000 (19:53 +0800)]
MdeModulePkg/PciHostBridgeLib.h: add address Translation

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>
6 years agoOvmfPkg/PciHostBridgeLib: clear PCI aperture vars for (re)init
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>
6 years agoCorebootPayloadPkg/PciHostBridgeLib: clear aperture vars for (re)init
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>
6 years agoArmPkg/TimerDxe: Add ISB for timer compare value reload
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.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
6 years agoBaseTools: UPT: remove unused variable and inaccessible code.
Carsey, Jaben [Mon, 12 Mar 2018 14:24:56 +0000 (22:24 +0800)]
BaseTools: UPT: remove unused variable and inaccessible code.

gINCLUDE_PATTERN is never used.
IncList is always empty.

Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
6 years agoSourceLevelDebugPkg DebugUsb3: Re-Support IOMMU
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>
6 years agoSourceLevelDebugPkg DebugCommUsb3: Refine some formats/comments
Star Zeng [Thu, 1 Mar 2018 02:10:29 +0000 (10:10 +0800)]
SourceLevelDebugPkg DebugCommUsb3: Refine some formats/comments

Refine some formats/comments and remove some unused prototypes.

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>
6 years agoSourceLevelDebugPkg DebugUsb3: Re-Fix GCC build failures
Star Zeng [Thu, 8 Feb 2018 08:01:06 +0000 (16:01 +0800)]
SourceLevelDebugPkg DebugUsb3: Re-Fix GCC build failures

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.

ad6040ec9b5bbc462762331f9738b8e42c0b9c80 needs to be also reverted
when reverting IOMMU support patches, otherwise there will be conflict.
This patch is to re-do ad6040ec9b5bbc462762331f9738b8e42c0b9c80.

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>
6 years agoRevert "DebugUsb3: Support IOMMU"
Star Zeng [Wed, 14 Mar 2018 08:09:36 +0000 (16:09 +0800)]
Revert "DebugUsb3: Support IOMMU"

This reverts commit de8373fa07f87ca735139bb86c51e2c29fb1d956.

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>
6 years agoRevert "DebugUsb3: Fix GCC build failures"
Star Zeng [Wed, 14 Mar 2018 08:09:10 +0000 (16:09 +0800)]
Revert "DebugUsb3: Fix GCC build failures"

This reverts commit ad6040ec9b5bbc462762331f9738b8e42c0b9c80.

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>
6 years agoRevert "DebugUsb3: Check mUsb3Instance before dereferencing it"
Star Zeng [Wed, 14 Mar 2018 08:08:41 +0000 (16:08 +0800)]
Revert "DebugUsb3: Check mUsb3Instance before dereferencing it"

This reverts commit 6ef394ffe29bbc67038fc16ed540bfe6eed10e16.

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>
6 years agoArmVirtPkg/PlatformBootManagerLib: minimize the set of connected devices
Laszlo Ersek [Tue, 13 Mar 2018 18:32:55 +0000 (19:32 +0100)]
ArmVirtPkg/PlatformBootManagerLib: minimize the set of connected devices

Prefer ConnectDevicesFromQemu() to EfiBootManagerConnectAll().

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
6 years agoOvmfPkg/PlatformBootManagerLib: minimize the set of connected devices
Laszlo Ersek [Tue, 13 Mar 2018 18:32:55 +0000 (19:32 +0100)]
OvmfPkg/PlatformBootManagerLib: minimize the set of connected devices

Prefer ConnectDevicesFromQemu() to EfiBootManagerConnectAll().

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
6 years agoOvmfPkg/QemuBootOrderLib: add ConnectDevicesFromQemu()
Laszlo Ersek [Tue, 13 Mar 2018 17:37:17 +0000 (18:37 +0100)]
OvmfPkg/QemuBootOrderLib: add ConnectDevicesFromQemu()

QemuBootOrderLib expects PlatformBootManagerLib to call the following
triplet:

(1) EfiBootManagerConnectAll(),
(2) EfiBootManagerRefreshAllBootOption(),
(3) SetBootOrderFromQemu().

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.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
6 years agoOvmfPkg/QemuBootOrderLib: clean up translation of virtio-net over MMIO
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(".

While at it, remove a bogus comment on PCI.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
6 years agoOvmfPkg/QemuBootOrderLib: add missing EFIAPI specifiers
Laszlo Ersek [Tue, 13 Mar 2018 15:41:14 +0000 (16:41 +0100)]
OvmfPkg/QemuBootOrderLib: add missing EFIAPI specifiers

Public library APIs should be declared as EFIAPI.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
6 years agoOvmfPkg/QemuBootOrderLib: wrap overlong line
Laszlo Ersek [Tue, 13 Mar 2018 16:37:03 +0000 (17:37 +0100)]
OvmfPkg/QemuBootOrderLib: wrap overlong line

81 characters is too many.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
6 years agoMdeModulePkg/PiSmmCore: fix mem alloc issues in heap guard
Jian J Wang [Tue, 13 Mar 2018 08:29:51 +0000 (16:29 +0800)]
MdeModulePkg/PiSmmCore: fix mem alloc issues in heap guard

This patch fixes the same issues in Heap Guard in DXE core, which is fixed
in another patch.

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>
6 years agoMdeModulePkg/Core: fix mem alloc issues in heap guard
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>
6 years agoShellPkg/[hex]edit: Fix mouse freeze issue
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().

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
6 years agoOvmfPkg/Gop: clear the screen to black in SetMode()
Ruiyu Ni [Tue, 13 Mar 2018 10:05:16 +0000 (18:05 +0800)]
OvmfPkg/Gop: clear the screen to black in SetMode()

Today's implementation forgot to clear the screen to black in
SetMode(). It causes SCT SetMode() test fails.

The patch adds the clear screen operation in SetMode() to fix
the SCT failure.

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>
6 years agoEmbeddedPkg: Correct the way of handling sections with a large size
Ge Song [Thu, 8 Mar 2018 00:55:10 +0000 (08:55 +0800)]
EmbeddedPkg: Correct the way of handling sections with a large size

Correct the way of handling EFI_SECTION_GUID_DEFINED type sections
with a large size

Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ge Song <ge.song@hxt-semitech.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
6 years agoOvmfPkg/XenPvBlkDxe: list "DriverBinding.h" in the INF file
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>
6 years agoOvmfPkg/XenPvBlkDxe: sort [Sources*] sections in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:22:08 +0000 (21:22 +0100)]
OvmfPkg/XenPvBlkDxe: sort [Sources*] sections in the INF file

This makes it easier to insert future source files. No functional changes.

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>
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>
6 years agoOvmfPkg/VirtioScsiDxe: list "VirtioScsi.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 22:55:37 +0000 (23:55 +0100)]
OvmfPkg/VirtioScsiDxe: list "VirtioScsi.h" in the INF file

Among other things, the header file defines macros and types that are
private to the driver and are used by the sole C file of the driver.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/VirtioRngDxe: list "VirtioRng.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 22:55:37 +0000 (23:55 +0100)]
OvmfPkg/VirtioRngDxe: list "VirtioRng.h" in the INF file

The header file defines macros and types that are private to the driver
and are used by the sole C file of the driver.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/VirtioPciDeviceDxe: list "VirtioPciDevice.h" in the INF file
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".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/VirtioNetDxe: list "VirtioNet.h" in the INF file
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.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/VirtioBlkDxe: list "VirtioBlk.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 22:55:37 +0000 (23:55 +0100)]
OvmfPkg/VirtioBlkDxe: list "VirtioBlk.h" in the INF file

Among other things, the header file defines macros and types that are
private to the driver and are used by the sole C file of the driver.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/Virtio10Dxe: list "Virtio10.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 22:55:37 +0000 (23:55 +0100)]
OvmfPkg/Virtio10Dxe: list "Virtio10.h" in the INF file

The header file defines macros and types that are private to the driver
and are used by the sole C file of the driver.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/QemuVideoDxe: list "VbeShim.h" in the INF file
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>
6 years agoOvmfPkg/QemuVideoDxe: list "UnalignedIoInternal.h" in the INF file
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>
6 years agoOvmfPkg/QemuVideoDxe: list "Qemu.h" in the INF file
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>
6 years agoOvmfPkg/QemuVideoDxe: sort [Sources*] sections in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:22:08 +0000 (21:22 +0100)]
OvmfPkg/QemuVideoDxe: sort [Sources*] sections in the INF file

This makes it easier to insert future source files. No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "QemuFlash.h" in INF files
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.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "FwBlockService.h" in INFs
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.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/PlatformPei: list "Xen.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 21:40:32 +0000 (22:40 +0100)]
OvmfPkg/PlatformPei: list "Xen.h" in the INF file

The header defines the OVMF_INFO_PHYSICAL_ADDRESS macro and the
EFI_XEN_OVMF_INFO structure, which are used in "Xen.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>
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>
6 years agoOvmfPkg/PlatformPei: list "Platform.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 21:34:41 +0000 (22:34 +0100)]
OvmfPkg/PlatformPei: list "Platform.h" in the INF file

The header file declares several functions and global variables that are
shared between various translation units in this module.

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>
6 years agoOvmfPkg/PlatformPei: list "Cmos.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 21:25:58 +0000 (22:25 +0100)]
OvmfPkg/PlatformPei: list "Cmos.h" in the INF file

The header file declares the CmosRead8() and CmosWrite8() functions, which
are implemented in "Cmos.c" and called from "MemDetect.c" and
"Platform.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>
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>
6 years agoOvmfPkg/PlatformDxe: list "PlatformConfig.h" in the INF file
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".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/PlatformDxe: list "Platform.h" in the INF file
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".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/VirtioMmioDeviceLib: improve style of mMmioDeviceProtocolTemplate
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.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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>
6 years agoOvmfPkg/VirtioMmioDeviceLib: list "VirtioMmioDevice.h" in the INF file
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".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/SerializeVariablesLib: list "SerializeVariablesLib.h" in INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:47:09 +0000 (21:47 +0100)]
OvmfPkg/SerializeVariablesLib: list "SerializeVariablesLib.h" in INF file

The header file defines macros and types for "SerializeVariablesLib.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>
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>
6 years agoOvmfPkg/QemuBootOrderLib: list "ExtraRootBusMap.h" in the INF file
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".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/QemuBootOrderLib: sort [Sources*] sections in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:22:08 +0000 (21:22 +0100)]
OvmfPkg/QemuBootOrderLib: sort [Sources*] sections in the INF file

This makes it easier to insert future source files. No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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>
6 years agoOvmfPkg/PlatformDebugLibIoPort: list "DebugLibDetect.h" in the INF files
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.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/NvVarsFileLib: list "NvVarsFileLib.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:05:36 +0000 (21:05 +0100)]
OvmfPkg/NvVarsFileLib: list "NvVarsFileLib.h" in the INF file

The header file declares LoadNvVarsFromFs() and SaveNvVarsToFs(), which
are defined in "FsAccess.c" and called from "NvVarsFileLib.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>
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>
6 years agoOvmfPkg/LockBoxLib: list "LockBoxLib.h" in the INF files
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.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/LoadLinuxLib: list "LoadLinuxLib.h" in the INF file
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".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/BaseMemEncryptSevLib: list "X64/VirtualMemory.h" in the INF file
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".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/AcpiTimerLib: list "AcpiTimerLib.h" in the INF files
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).

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/IoMmuDxe: list "AmdSevIoMmu.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 19:20:14 +0000 (20:20 +0100)]
OvmfPkg/IoMmuDxe: list "AmdSevIoMmu.h" in the INF file

The header file declares the AmdSevInstallIoMmuProtocol() function, which
is implemented in "AmdSevIoMmu.c" and called from "IoMmuDxe.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
6 years agoOvmfPkg/EmuVariableFvbRuntimeDxe: list "Fvb.h" in the INF file
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>
6 years agoOvmfPkg/CsmSupportLib: list "LegacyRegion.h" in the INF file
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.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/CsmSupportLib: list "LegacyPlatform.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "LegacyPlatform.h" in the INF file

The header file defines types and macros for "LegacyPlatform.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/CsmSupportLib: list "LegacyInterrupt.h" in the INF file
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.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/CsmSupportLib: list "CsmSupportLib.h" in the INF file
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".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/CsmSupportLib: sort [Sources*] sections in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 18:45:45 +0000 (19:45 +0100)]
OvmfPkg/CsmSupportLib: sort [Sources*] sections in the INF file

This makes it easier to insert future source files. No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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>
6 years agoOvmfPkg/BlockMmioToBlockIoDxe: list "BlockIo.h" in the INF file
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".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
6 years agoOvmfPkg/AcpiPlatformDxe: list "QemuLoader.h" in the INF files
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>
6 years agoOvmfPkg/AcpiPlatformDxe: don't #include "QemuLoader.h" in "Qemu.c"
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>
6 years agoOvmfPkg/AcpiPlatformDxe: list "AcpiPlatform.h" in the INF files
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>
6 years agoOvmfPkg/AcpiPlatformDxe: sort [Sources*] sections in the INF files
Laszlo Ersek [Sat, 10 Mar 2018 17:10:02 +0000 (18:10 +0100)]
OvmfPkg/AcpiPlatformDxe: sort [Sources*] sections in the INF files

This makes it easier to insert future source files, and to see the source
files that are unique to either INF file. No functional changes.

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>
6 years agoArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: list "PrePi.h" in INF file
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".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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>
6 years agoArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: sort [Sources*] sections in INF
Laszlo Ersek [Sat, 10 Mar 2018 17:06:10 +0000 (18:06 +0100)]
ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: sort [Sources*] sections in INF

This makes it easier to insert future source files. No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
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>
6 years agoArmVirtPkg/PlatformBootManagerLib: list "PlatformBm.h" in INF file
Laszlo Ersek [Sat, 10 Mar 2018 16:44:54 +0000 (17:44 +0100)]
ArmVirtPkg/PlatformBootManagerLib: list "PlatformBm.h" in INF file

The header file declares TryRunningQemuKernel(), defined in "QemuKernel.c"
and called from "PlatformBm.c".

Cc: Ard Biesheuvel <ard.biesheuvel@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>
6 years agoMdeModulePkg PCD: Remove PCD_TYPE_SKU_ENABLED in PCD_TYPE_ALL_SET
Star Zeng [Tue, 13 Mar 2018 09:03:11 +0000 (17:03 +0800)]
MdeModulePkg PCD: Remove PCD_TYPE_SKU_ENABLED in PCD_TYPE_ALL_SET

Remove PCD_TYPE_SKU_ENABLED in PCD_TYPE_ALL_SET.
This change was missing at e8d2a9805286a2fd4f613697cf0cccb4a1ebc90d.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Eric Dong <eric.dong@intel.com>
6 years agoNetworkPkg/IScsiDxe: Fix the ISCSI connection failure in certain case.
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>
6 years agoMdeModulePkg/Mtftp4Dxe: Fix the incorrect return status.
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>
6 years agoMdeModulePkg PCD: Remove unused PCD attribute PCD_TYPE_SKU_ENABLED
Gao, Liming [Wed, 7 Mar 2018 08:15:18 +0000 (16:15 +0800)]
MdeModulePkg PCD: Remove unused PCD attribute PCD_TYPE_SKU_ENABLED

PcdDb optimization has handled PCD DB for each SKU, not for single PCD.
So, this PCD attribute is not used any more.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
6 years agoBaseTools: Get Pcd DatumType from DEC file for --pcd
Yonghong Zhu [Mon, 12 Mar 2018 07:09:03 +0000 (15:09 +0800)]
BaseTools: Get Pcd DatumType from DEC file for --pcd

It is regression bug that missing the Pcd DatumType info from DEC file
for --pcd .

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
6 years agoIntelSiliconPkg/Vtd: Add missing dump in ExtContext.
Jiewen Yao [Fri, 9 Mar 2018 03:50:58 +0000 (11:50 +0800)]
IntelSiliconPkg/Vtd: Add missing dump in ExtContext.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
6 years agoIntelSiliconPkg/Vtd: Add DMA_CTRL_PLATFORM_OPT_IN_FLAG dump
Jiewen Yao [Thu, 8 Mar 2018 12:40:57 +0000 (20:40 +0800)]
IntelSiliconPkg/Vtd: Add DMA_CTRL_PLATFORM_OPT_IN_FLAG dump

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
6 years agoSecurityPkg/TcgPei: drop PeiReadOnlyVariable from Depex
Laszlo Ersek [Fri, 9 Mar 2018 19:06:31 +0000 (20:06 +0100)]
SecurityPkg/TcgPei: drop PeiReadOnlyVariable from Depex

TcgPei doesn't actually use the PEI-phase read-only variable service, so
drop that from the Depex.

This patch was inspired by commit ab9e11da6651 ("SecurityPkg/Tcg2Pei: drop
PeiReadOnlyVariable from Depex", 2018-03-09).

Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Suggested-by: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
6 years agoOvmfPkg/Tcg2ConfigPei: trivial coding style updates
Laszlo Ersek [Fri, 9 Mar 2018 18:54:20 +0000 (19:54 +0100)]
OvmfPkg/Tcg2ConfigPei: trivial coding style updates

- the @file comment block should match between INF and main C file

- rewrap / refill columns to 79 characters

- insert space before opening paren

- prefix and suffix //-style comment block with empty // lines

- fix indentation of arguments in multi-line function call

- general tab spacing (indent step) is 2 in edk2, unlike QEMU's 4

No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
6 years agoOvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active
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.

Cc: Jordan Justen <jordan.l.justen@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: Brijesh Singh <brijesh.singh@amd.com>
[lersek@redhat.com: trivial coding style improvements]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
6 years agoOvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe
Marc-André Lureau [Thu, 22 Feb 2018 18:10:03 +0000 (19:10 +0100)]
OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe

The library registers a security management handler, to measure images
that are not measure in PEI phase. For example with the qemu PXE rom:

Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi

And the following binary_bios_measurements log entry seems to be
added:

PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER      size: 0x4e digest: 70a22475e9f18806d2ed9193b48d80d26779d9a4

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".

(5) OVMF's PlatformBootManagerLib signals EndOfDxe.

(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).

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
6 years agoOvmfPkg: include Tcg2Dxe module
Marc-André Lureau [Thu, 22 Feb 2018 16:53:16 +0000 (17:53 +0100)]
OvmfPkg: include Tcg2Dxe module

This module measures and log the boot environment. It also produces
the Tcg2 protocol, which allows for example to read the log from OS.

The linux kernel doesn't yet read the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2,
which is required for crypto-agile log. In fact, only upcoming 4.16
adds support EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2:

[    0.000000] efi: EFI v2.70 by EDK II
[    0.000000] efi:  SMBIOS=0x3fa1f000  ACPI=0x3fbb6000  ACPI 2.0=0x3fbb6014  MEMATTR=0x3e7d4318  TPMEventLog=0x3db21018

$ python chipsec_util.py tpm parse_log binary_bios_measurements

[CHIPSEC] Version 1.3.5.dev2
[CHIPSEC] API mode: using OS native API (not using CHIPSEC kernel module)
[CHIPSEC] Executing command 'tpm' with args ['parse_log', '/tmp/binary_bios_measurements']

PCR: 0 type: EV_S_CRTM_VERSION                size: 0x2 digest: 1489f923c4dca729178b3e3233458550d8dddf29
+ version:
PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB    size: 0x10 digest: fd39ced7c0d2a61f6830c78c7625f94826b05bcc
+ base: 0x820000 length: 0xe0000
PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB    size: 0x10 digest: 39ebc6783b72bc1e73c7d5bcfeb5f54a3f105d4c
+ base: 0x900000 length: 0xa00000
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x35 digest: 57cd4dc19442475aa82743484f3b1caa88e142b8
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x24 digest: 9b1387306ebb7ff8e795e7be77563666bbf4516e
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x26 digest: 9afa86c507419b8570c62167cb9486d9fc809758
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x24 digest: 5bf8faa078d40ffbd03317c93398b01229a0e1e0
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x26 digest: 734424c9fe8fc71716c42096f4b74c88733b175e
PCR: 7 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x3e digest: 252f8ebb85340290b64f4b06a001742be8e5cab6
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x6e digest: 22a4f6ee9af6dba01d3528deb64b74b582fc182b
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x80 digest: b7811d5bf30a7efd4e385c6179fe10d9290bb9e8
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x84 digest: 425e502c24fc924e231e0a62327b6b7d1f704573
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x9a digest: 0b5d2c98ac5de6148a4a1490ff9d5df69039f04e
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0xbd digest: 20bd5f402271d57a88ea314fe35c1705956b1f74
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x88 digest: df5d6605cb8f4366d745a8464cfb26c1efdc305c
PCR: 4 type: EV_EFI_ACTION                    size: 0x28 digest: cd0fdb4531a6ec41be2753ba042637d6e5f7f256
PCR: 0 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 2 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 3 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 4 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 5 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473

$ tpm2_pcrlist
sha1 :
  0  : 35bd1786b6909daad610d7598b1d620352d33b8a
  1  : ec0511e860206e0af13c31da2f9e943fb6ca353d
  2  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  3  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  4  : 45a323382bd933f08e7f0e256bc8249e4095b1ec
  5  : d16d7e629fd8d08ca256f9ad3a3a1587c9e6cc1b
  6  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  7  : 518bd167271fbb64589c61e43d8c0165861431d8
  8  : 0000000000000000000000000000000000000000
  9  : 0000000000000000000000000000000000000000
  10 : 0000000000000000000000000000000000000000
  11 : 0000000000000000000000000000000000000000
  12 : 0000000000000000000000000000000000000000
  13 : 0000000000000000000000000000000000000000
  14 : 0000000000000000000000000000000000000000
  15 : 0000000000000000000000000000000000000000
  16 : 0000000000000000000000000000000000000000
  17 : ffffffffffffffffffffffffffffffffffffffff
  18 : ffffffffffffffffffffffffffffffffffffffff
  19 : ffffffffffffffffffffffffffffffffffffffff
  20 : ffffffffffffffffffffffffffffffffffffffff
  21 : ffffffffffffffffffffffffffffffffffffffff
  22 : ffffffffffffffffffffffffffffffffffffffff
  23 : 0000000000000000000000000000000000000000
sha256 :
  0  : 9ae903dbae3357ac00d223660bac19ea5c021499a56201104332ab966631ce2c
  1  : acc611d90245cf04e77b0ca94901f90e7fa54770f0426f53c3049b532243d1b8
  2  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  3  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  4  : 7a94ffe8a7729a566d3d3c577fcb4b6b1e671f31540375f80eae6382ab785e35
  5  : a5ceb755d043f32431d63e39f5161464620a3437280494b5850dc1b47cc074e0
  6  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  7  : 65caf8dd1e0ea7a6347b635d2b379c93b9a1351edc2afc3ecda700e534eb3068
  8  : 0000000000000000000000000000000000000000000000000000000000000000
  9  : 0000000000000000000000000000000000000000000000000000000000000000
  10 : 0000000000000000000000000000000000000000000000000000000000000000
  11 : 0000000000000000000000000000000000000000000000000000000000000000
  12 : 0000000000000000000000000000000000000000000000000000000000000000
  13 : 0000000000000000000000000000000000000000000000000000000000000000
  14 : 0000000000000000000000000000000000000000000000000000000000000000
  15 : 0000000000000000000000000000000000000000000000000000000000000000
  16 : 0000000000000000000000000000000000000000000000000000000000000000
  17 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  18 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  19 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  20 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  21 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  22 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  23 : 0000000000000000000000000000000000000000000000000000000000000000
sha384 :

The PhysicalPresenceLib is required, it sets some variables, but the
firmware doesn't act on it yet.

Laszlo Ersek explained on the list why Tpm2DeviceLib has to be
resolved differently for DXE_DRIVER modules in general and for
"Tcg2Dxe.inf" specifically:

  * We have a library class called Tpm2DeviceLib -- this is basically the
  set of APIs declared in "SecurityPkg/Include/Library/Tpm2DeviceLib.h".
  Its leading comment says "This library abstract how to access TPM2
  hardware device".

  There are two *sets* of APIs in "Tpm2DeviceLib.h":

  (a) functions that deal with the TPM2 device:
      - Tpm2RequestUseTpm(),
      - Tpm2SubmitCommand()

      This set of APIs is supposed to be used by clients that *consume*
      the TPM2 device abstraction.

  (b) the function Tpm2RegisterTpm2DeviceLib(), which is supposed to be
      used by *providers* of various TPM2 device abstractions.

  * Then, we have two implementations (instances) of the Tpm2DeviceLib class:
  (1) SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
  (2) SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf

  (1) The first library instance ("Tpm2DeviceLibTcg2.inf") implements the
  APIs listed under (a), and it does not implement (b) -- see
  EFI_UNSUPPORTED. In other words, this lib instance is strictly meant for
  drivers that *consume* the TPM2 device abstraction. And, the (a) group
  of APIs is implemented by forwarding the requests to the TCG2 protocol.

  The idea here is that all the drivers that consume the TPM2 abstraction
  do not have to be statically linked with a large TPM2 device library
  instance; instead they are only linked (statically) with this "thin"
  library instance, and all the actual work is delegated to whichever
  driver that provides the singleton TCG2 protocol.

  (2) The second library instance ("Tpm2DeviceLibRouterDxe.inf") is meant
  for the driver that offers (produces) the TCG2 protocol. This lib
  instance implements both (a) and (b) API groups.

  * Here's how things fit together:

  (i) The "SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf"
  library instance (which has no lib class) is linked into "Tcg2Dxe.inf"
  via NULL class resolution. This simply means that before the
  "Tcg2Dxe.inf" entry point function is entered, the constructor function
  of "Tpm2InstanceLibDTpm.inf" will be called.

  (ii) This Tpm2InstanceLibDTpmConstructor() function calls API (b), and
  registers its own actual TPM2 command implementation with the
  "Tpm2DeviceLibRouter" library instance (also linked into the Tcg2Dxe
  driver). This provides the back-end for the API set (a).

         TCG2 protocol provider (Tcg2Dxe.inf driver) launches
                      |
                      v
    NULL class: Tpm2InstanceLibDTpm instance construction
                      |
                      v
    Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
           backend registration for API set (a)

  (iii) The Tcg2Dxe driver exposes the TCG2 protocol.

  (iv) A TPM2 consumer calls API set (a) via lib instance (1). Such calls
  land in Tcg2Dxe, via the protocol.

  (v) Tcg2Dxe serves the protocol request by forwarding it to API set (a)
  from lib instance (2).

  (vi) Those functions call the "backend" functions registered by
  Tpm2DeviceLibDTpm in step (ii).

       TPM 2 consumer driver
                |
                v
  Tpm2DeviceLib class: Tpm2DeviceLibTcg2 instance
                |
                v
         TCG2 protocol interface
                |
                v
  TCG2 protocol provider: Tcg2Dxe.inf driver
                |
                v
  Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
                |
                v
     NULL class: Tpm2InstanceLibDTpm instance
        (via earlier registration)
                |
                v
       TPM2 chip (actual hardware)

  * So that is the "router" pattern in edk2. Namely,

  - Consumers of an abstraction use a thin library instance.

  - The thin library instance calls a firmware-global (singleton) service,
    i.e. a PPI (in the PEI phase) or protocol (in the DXE phase).

  - The PEIM providing the PPI, or the DXE driver providing the protocol,
    don't themselves implement the actual service either. Instead they
    offer a "registration" service too, and they only connect the incoming
    "consumer" calls to the earlier registered back-end(s).

  - The "registration service", for back-ends to use, may take various
    forms.

    It can be exposed globally to the rest of the firmware, as
    another member function of the PPI / protocol structure. Then backends
    can be provided by separate PEIMs / DXE drivers.

    Or else, the registration service can be exposed as just another
    library API. In this case, the backends are provided as NULL class
    library instances, and a platform  DSC file links them into the PEIM /
    DXE driver via NULL class resolutions. The backend lib instances call
    the registration service in their own respective constructor
    functions.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
6 years agoOvmfPkg: include Tcg2Pei module
Marc-André Lureau [Thu, 22 Feb 2018 14:26:34 +0000 (15:26 +0100)]
OvmfPkg: include Tcg2Pei module

This module will initialize TPM device, measure reported FVs and BIOS
version. We keep both SHA-1 and SHA-256 for the TCG 1.2 log format
compatibility, but the SHA-256 measurements and TCG 2 log format are
now recommended.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
6 years agoOvmfPkg: add customized Tcg2ConfigPei clone
Marc-André Lureau [Thu, 22 Feb 2018 13:20:58 +0000 (14:20 +0100)]
OvmfPkg: add customized Tcg2ConfigPei clone

The Tcg2ConfigPei module informs the firmware globally about the TPM
device type, by setting the PcdTpmInstanceGuid PCD to the appropriate
GUID value. The original module under SecurityPkg can perform device
detection, or read a cached value from a non-volatile UEFI variable.

OvmfPkg's clone of the module only performs the TPM2 hardware detection.

This is what the module does:

- Check the QEMU hardware for TPM2 availability only

- If found, set the dynamic PCD "PcdTpmInstanceGuid" to
  &gEfiTpmDeviceInstanceTpm20DtpmGuid. This is what informs the rest of
  the firmware about the TPM type.

- Install the gEfiTpmDeviceSelectedGuid PPI. This action permits the
  PEI_CORE to dispatch the Tcg2Pei module, which consumes the above PCD.
  In effect, the gEfiTpmDeviceSelectedGuid PPI serializes the setting
  and the consumption of the "TPM type" PCD.

- If no TPM2 was found, install gPeiTpmInitializationDonePpiGuid.
  (Normally this is performed by Tcg2Pei, but Tcg2Pei doesn't do it if
  no TPM2 is available. So in that case our Tcg2ConfigPei must do it.)

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
6 years agoOvmfPkg: simplify SecurityStubDxe.inf inclusion
Marc-André Lureau [Mon, 5 Mar 2018 16:14:18 +0000 (17:14 +0100)]
OvmfPkg: simplify SecurityStubDxe.inf inclusion

SecurityStubDxe.inf should be included unconditionally.

Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
6 years agoMdeModulePkg/Core/Pei: fix REGISITER -> REGISTER typo
Marc-André Lureau [Fri, 2 Mar 2018 17:19:33 +0000 (18:19 +0100)]
MdeModulePkg/Core/Pei: fix REGISITER -> REGISTER typo

No functional changes.

Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
6 years agoSecurityPkg/Tcg2Pei: drop PeiReadOnlyVariable from Depex
Marc-André Lureau [Thu, 1 Mar 2018 15:09:39 +0000 (16:09 +0100)]
SecurityPkg/Tcg2Pei: drop PeiReadOnlyVariable from Depex

The module doesn't use read-only variable.

Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
6 years agoBaseTools: GlobalData remove unused variable
Carsey, Jaben [Thu, 8 Mar 2018 00:45:18 +0000 (08:45 +0800)]
BaseTools: GlobalData remove unused variable

gWideStringPattern is not used.

Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
6 years agoBaseTools: Fix parse OFFSET_OF get wrong offset
Feng, YunhuaX [Fri, 9 Mar 2018 08:46:00 +0000 (16:46 +0800)]
BaseTools: Fix parse OFFSET_OF get wrong offset

Fix parse OFFSET_OF get wrong offset

Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>