Place the EFI shell as EFI/BOOT/BOOT{ARCH}.EFI on the virtual drive.
This allows the "run to shell" CI test case to work even in case the
shell is not included in the firmware image.
This is needed because an followup patch will exclude the shell from
secure boot enabled firmware images.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Message-Id: <20240222101358.67818-12-kraxel@redhat.com>
Note that IntelTdxX64 is compiled without network support, so thanks to
the network conditionals in the include files the build result (network
shell commands excluded) should be identical before and after the patch.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Message-Id: <20240222101358.67818-10-kraxel@redhat.com>
Note that AmdSevX64 is compiled without network support, so thanks to
the network conditionals in the include files the build result (network
shell commands excluded) should be identical before and after the patch.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Message-Id: <20240222101358.67818-9-kraxel@redhat.com>
XenRealTimeClockLib is used to back the runtime services time functions,
so align the description of the function return values with the
defined values for these services as described in UEFI Spec 2.10.
REF: UEFI spec 2.10 section 8 Services ? Runtime Services
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Suqiang Ren <suqiangx.ren@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The current support within the boot SNP CPUID table processing mistakenly
swaps the ECX and EDX results. It does not have an effect at this time
because current CPUID results checking does not check ECX or EDX. However,
any future CPUID checks that need to check ECX or EDX may have erroneous
behavior.
Fix the assembler code to save ECX and EDX to the proper locations.
Fixes: 34819f2cac ("OvmfPkg/ResetVector: use SEV-SNP-validated CPUID values")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Michael Roth <michael.roth@amd.com>
A recent change to the PciIoMap() function now propagates the return code
from the IoMmu protocol SetAttribute() operation. The implementation of
this operation in OvmfPkg/IoMmuDxe/CcIoMmu.c returns EFI_UNSUPPORTED,
resulting in a failure to boot the guest.
Provide an implementation for SetAttribute() that validates the IoMmu
access method being requested against the IoMmu mapping operation.
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <c0f9e95f557b601a045da015c1a97201e8aec2ab.1706634932.git.thomas.lendacky@amd.com>
Tested-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
It is possible to find variable entries with State being 0xff, i.e. not
updated since flash block erase. This indicates the variable driver
could not complete the header write while appending a new entry, and
therefore State was not set to VAR_HEADER_VALID_ONLY.
This can only happen at the end of the variable list, so treat this as
additional "end of variable list" condition.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240116171105.37831-6-kraxel@redhat.com>
Raise the limit for writes without block erase from two to four
P30_MAX_BUFFER_SIZE_IN_BYTES blocks. With this in place almost all efi
variable updates are handled without block erase. With the old limit
some variable updates (with device paths) took the block erase code
path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240116171105.37831-5-kraxel@redhat.com>
Replace the two NorFlashWriteBuffer() calls with a loop containing a
single NorFlashWriteBuffer() call.
With the changes in place the code is able to handle updates larger
than two P30_MAX_BUFFER_SIZE_IN_BYTES blocks, even though the patch
does not actually change the size limit.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240116171105.37831-4-kraxel@redhat.com>
Introduce 'Start' and 'End' variables to make it easier to follow the
logic and code flow. Also add a ascii art diagram (based on a
suggestion by Laszlo).
This also fixes the 'Size' calculation for the NorFlashRead() call.
Without this patch the code will read only one instead of two
P30_MAX_BUFFER_SIZE_IN_BYTES blocks in case '*NumBytes' is smaller than
P30_MAX_BUFFER_SIZE_IN_BYTES but 'Offset + *NumBytes' is not, i.e. the
update range crosses a P30_MAX_BUFFER_SIZE_IN_BYTES boundary.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240116171105.37831-3-kraxel@redhat.com>
Without enabling PcdUse1GPageTable, CloudHv guests are limited
to a 40-bit address space, even if the hardware supports more.
This limits the amount of RAM to 1TiB of CloudHv guests.
Signed-off-by: Thomas Barrett <tbarrett@crusoeenergy.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
In addition to initializing the PhysMemAddressWidth and
FirstNonAddress fields in PlatformInfoHob, the
PlatformAddressWidthInitialization function is responsible
for initializing the PcdPciMmio64Base and PcdPciMmio64Size
fields.
Currently, for CloudHv guests, the PcdPciMmio64Base is
placed immediately after either the 4G boundary or the
last RAM region, whichever is greater. We do not change
this behavior.
Previously, when booting CloudHv guests with greater than
1TiB of high memory, the PlatformAddressWidthInitialization
function incorrect calculates the amount of RAM using the
overflowed 24-bit CMOS register.
Now, we update the PlatformAddressWidthInitialization
behavior on CloudHv to scan the E820 entries to detect
the amount of RAM. This allows CloudHv guests to boot with
greater than 1TiB of RAM
Signed-off-by: Thomas Barrett <tbarrett@crusoeenergy.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The PlatformScanE820 utility function is not currently compatible
with CloudHv since it relies on the prescence of the "etc/e820"
QemuFwCfg file. Update the PlatformScanE820 to iterate through the
PVH e820 entries when running on a CloudHv guest.
Signed-off-by: Thomas Barrett <tbarrett@crusoeenergy.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Only need to include Network.dsc.inc to have all network
drivers/components be built. Otherwise, there were missing definition
that prevent them from be built for RiscVVirt platform.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Extend the ValidateFvHeader function, additionally to the header checks
walk over the list of variables and sanity check them.
In case we find inconsistencies indicating variable store corruption
return EFI_NOT_FOUND so the variable store will be re-initialized.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20240109112902.30002-4-kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: fix StartId initialization/assignment coding style]
Only accept gEfiAuthenticatedVariableGuid when checking the variable
store header in ValidateFvHeader().
The edk2 code base has been switched to use the authenticated varstore
format unconditionally (even in case secure boot is not used or
supported) a few years ago.
Suggested-by: László Érsek <lersek@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240109112902.30002-3-kraxel@redhat.com>
The struct used for GHCB-based page-state change requests uses a 40-bit
bit-field for the GFN, which is shifted by PAGE_SHIFT to generate a
64-bit address. However, anything beyond 40-bits simply gets shifted off
when doing this, which will cause issues when dealing with 1TB+
addresses. Fix this by casting the 40-bit GFN values to 64-bit ones
prior to shifting it by PAGE_SHIFT.
Fixes: ade62c18f4 ("OvmfPkg/MemEncryptSevLib: add support to validate system RAM")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-Id: <20231115175153.813213-1-michael.roth@amd.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
8259InterruptControllerDxe is not used by any platforms at this point,
remove it.
This patch removes mentions of the following CSM resources from the source
code:
- GUIDs (protocols or otherwise):
- gEfiLegacy8259ProtocolGuid
- headers:
- Protocol/Legacy8259.h
- PCDs:
- Pcd8259LegacyModeEdgeLevel
- Pcd8259LegacyModeMask
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiLegacy8259ProtocolGuid
- headers:
- Protocol/Legacy8259.h
- PCDs:
- Pcd8259LegacyModeEdgeLevel
- Pcd8259LegacyModeMask
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-35-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
