diff options
| author | Sebastien Boeuf <sebastien.boeuf@intel.com> | 2022-05-10 20:50:43 +0800 |
|---|---|---|
| committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2022-06-03 10:51:26 +0000 |
| commit | 5c9f151e0c8c0a881bc374ec52fef07714735a82 (patch) | |
| tree | d3570839475c16b44eb87055d389f2c34da1ff0d /BaseTools/Source/Python/AutoGen/GenVar.py | |
| parent | 632574ced10fe184d5665b73c62c959109c39961 (diff) | |
| download | edk2-5c9f151e0c8c0a881bc374ec52fef07714735a82.tar.gz edk2-5c9f151e0c8c0a881bc374ec52fef07714735a82.tar.bz2 edk2-5c9f151e0c8c0a881bc374ec52fef07714735a82.zip | |
OvmfPkg: CloudHv: Fix FW_BASE_ADDRESS
The FW_BASE_ADDRESS value provided by OvmfPkgDefines.fdf.inc is
incorrect for the CloudHv target. We know the generated firmware
contains a PVH ELF header, meaning it will be loaded according to the
address provided through this header. And since we know this address
isn't going to change as it's part of CloudHvElfHeader.fdf.inc, we can
hardcode it through a new include file CloudHvDefines.fdf.inc, which
replaces the generic one OvmfPkgDefines.fdf.inc.
With this change, we prevent the firmware from accessing MMIO addresses
from the address range 0xffc00000-0xffffffff since we know the firmware
hasn't been loaded on this address range.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Diffstat (limited to 'BaseTools/Source/Python/AutoGen/GenVar.py')
0 files changed, 0 insertions, 0 deletions