* [Xen-devel] [PATCH v4 01/35] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 02/35] OvmfPkg: Create platform OvmfXen Anthony PERARD
` (35 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Add missing dependency on PciLib
and remove extra includes of OvmfPlatforms.h.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v2:
- also add PciLib.h include to the .c
- and remove extra include of OvmfPlatforms.h
OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 +
OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c | 3 +--
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
index 7c44f99a5c..2f24dac87f 100644
--- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
+++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
@@ -30,4 +30,5 @@ [Packages]
[LibraryClasses]
DebugLib
IoLib
+ PciLib
TimerLib
diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
index 27460cd100..98dd80e33c 100644
--- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -11,11 +11,10 @@
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
#include <Library/IoLib.h>
+#include <Library/PciLib.h>
#include <Library/TimerLib.h>
#include <OvmfPlatforms.h>
-#include <OvmfPlatforms.h>
-
VOID
AcpiPmControl (
UINTN SuspendType
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 02/35] OvmfPkg: Create platform OvmfXen
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 01/35] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 9:13 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 03/35] OvmfPkg: Introduce XenResetVector Anthony PERARD
` (34 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
OvmfXen is a copy of OvmfX64, removing VirtIO and some SMM.
This new platform will be changed to make it works on two types of Xen
guest: HVM and PVH.
Compare to OvmfX64, this patch:
- changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
- removed: VirtioLib class resolution
- removed: all UEFI_DRIVER modules for virtio devices
- removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
- removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
- removed: Everything related to SMM_REQUIRE==true
- removed: Everything related to SECURE_BOOT_ENABLE==true
- removed: Everything related to TPM2_ENABLE==true
- changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
- changed: default FD_SIZE_IN_KB to 2M.
- reverted d272449d9e1e, "OvmfPkg: raise DXEFV size to 11 MB"
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- rebased
- Update Maintainers.txt
v3:
- rebased, SPDX + 8259/8254 changes
OvmfPkg/OvmfXen.dsc | 729 ++++++++++++++++++++++++++++++++++++++++++++
OvmfPkg/OvmfXen.fdf | 439 ++++++++++++++++++++++++++
Maintainers.txt | 1 +
3 files changed, 1169 insertions(+)
create mode 100644 OvmfPkg/OvmfXen.dsc
create mode 100644 OvmfPkg/OvmfXen.fdf
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
new file mode 100644
index 0000000000..f224ac32b4
--- /dev/null
+++ b/OvmfPkg/OvmfXen.dsc
@@ -0,0 +1,729 @@
+## @file
+# EFI/Framework Open Virtual Machine Firmware (OVMF) platform
+#
+# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
+# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+################################################################################
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+################################################################################
+[Defines]
+ PLATFORM_NAME = Ovmf
+ PLATFORM_GUID = e3aa4fbe-9459-482d-bd40-d3f3b5f89d6e
+ PLATFORM_VERSION = 0.1
+ DSC_SPECIFICATION = 0x00010005
+ OUTPUT_DIRECTORY = Build/OvmfXen
+ SUPPORTED_ARCHITECTURES = X64
+ BUILD_TARGETS = NOOPT|DEBUG|RELEASE
+ SKUID_IDENTIFIER = DEFAULT
+ FLASH_DEFINITION = OvmfPkg/OvmfXen.fdf
+
+ #
+ # Defines for default states. These can be changed on the command line.
+ # -D FLAG=VALUE
+ #
+
+ #
+ # Network definition
+ #
+ DEFINE NETWORK_TLS_ENABLE = FALSE
+ DEFINE NETWORK_IP6_ENABLE = FALSE
+ DEFINE NETWORK_HTTP_BOOT_ENABLE = FALSE
+ DEFINE NETWORK_ALLOW_HTTP_CONNECTIONS = TRUE
+
+!include NetworkPkg/NetworkDefines.dsc.inc
+
+ #
+ # Flash size selection. Setting FD_SIZE_IN_KB on the command line directly to
+ # one of the supported values, in place of any of the convenience macros, is
+ # permitted.
+ #
+!ifdef $(FD_SIZE_1MB)
+ DEFINE FD_SIZE_IN_KB = 1024
+!else
+!ifdef $(FD_SIZE_2MB)
+ DEFINE FD_SIZE_IN_KB = 2048
+!else
+!ifdef $(FD_SIZE_4MB)
+ DEFINE FD_SIZE_IN_KB = 4096
+!else
+ DEFINE FD_SIZE_IN_KB = 2048
+!endif
+!endif
+!endif
+
+[BuildOptions]
+ GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
+ INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
+ MSFT:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
+!if $(TOOL_CHAIN_TAG) != "XCODE5"
+ GCC:*_*_*_CC_FLAGS = -mno-mmx -mno-sse
+!endif
+!ifdef $(SOURCE_DEBUG_ENABLE)
+ MSFT:*_*_X64_GENFW_FLAGS = --keepexceptiontable
+ GCC:*_*_X64_GENFW_FLAGS = --keepexceptiontable
+ INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
+!endif
+
+ #
+ # Disable deprecated APIs.
+ #
+ MSFT:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES
+ INTEL:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES
+ GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+
+[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
+ GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+ XCODE:*_*_*_DLINK_FLAGS =
+
+# Force PE/COFF sections to be aligned at 4KB boundaries to support page level
+# protection of DXE_SMM_DRIVER/SMM_CORE modules
+[BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
+ GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+ XCODE:*_*_*_DLINK_FLAGS =
+
+################################################################################
+#
+# SKU Identification section - list of all SKU IDs supported by this Platform.
+#
+################################################################################
+[SkuIds]
+ 0|DEFAULT
+
+################################################################################
+#
+# Library Class section - list of all Library Classes needed by this Platform.
+#
+################################################################################
+[LibraryClasses]
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
+ PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+ BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
+ BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+ SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
+ BmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf
+ SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
+ CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
+ PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
+ PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
+ CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
+ UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
+ UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
+ HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
+ SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
+ UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+ BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
+ FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
+ CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
+ DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
+ DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf
+ PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
+ PciCf8Lib|MdePkg/Library/BasePciCf8Lib/BasePciCf8Lib.inf
+ PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
+ PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf
+ PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
+ PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf
+ PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
+ PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+ IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
+ OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
+ SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
+ MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
+ UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
+ UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
+ UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
+ UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
+ UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
+ DevicePathLib|MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf
+ NvVarsFileLib|OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib.inf
+ FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
+ UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
+ SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
+ UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
+ SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf
+ QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxeLib.inf
+ LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
+ MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
+ LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
+ CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+ FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
+
+!ifdef $(SOURCE_DEBUG_ENABLE)
+ PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf
+ DebugCommunicationLib|SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommunicationLibSerialPort.inf
+!else
+ PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
+ DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
+!endif
+
+ ResetSystemLib|OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
+ LocalApicLib|UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
+ DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
+
+ IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
+!if $(NETWORK_TLS_ENABLE) == TRUE
+ OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
+!else
+ OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
+!endif
+
+ AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+ VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
+
+
+ #
+ # Network libraries
+ #
+!include NetworkPkg/NetworkLibs.dsc.inc
+
+!if $(NETWORK_TLS_ENABLE) == TRUE
+ TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
+!endif
+
+ ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+ ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
+ S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
+ SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
+ OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
+ XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+
+ Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
+ TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+
+[LibraryClasses.common]
+ BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+
+[LibraryClasses.common.SEC]
+ TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
+ QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+ DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+ DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
+!endif
+ ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
+ ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
+!ifdef $(SOURCE_DEBUG_ENABLE)
+ DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
+!endif
+ HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
+ PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
+ PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
+ MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
+ CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
+
+[LibraryClasses.common.PEI_CORE]
+ HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
+ PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
+ PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
+ MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
+ PeiCoreEntryPoint|MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
+ ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
+ OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
+ PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+ DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+ DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
+ PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
+
+[LibraryClasses.common.PEIM]
+ HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
+ PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
+ PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
+ MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
+ PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
+ ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
+ OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
+ PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+ DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+ DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
+ PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
+ ResourcePublicationLib|MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.inf
+ ExtractGuidedSectionLib|MdePkg/Library/PeiExtractGuidedSectionLib/PeiExtractGuidedSectionLib.inf
+!ifdef $(SOURCE_DEBUG_ENABLE)
+ DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
+!endif
+ CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
+ MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
+ QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
+ PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+ QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf
+
+[LibraryClasses.common.DXE_CORE]
+ HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
+ DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
+ MemoryAllocationLib|MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
+ ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+ DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+ DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
+ ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
+!ifdef $(SOURCE_DEBUG_ENABLE)
+ DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
+!endif
+ CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+ PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+
+[LibraryClasses.common.DXE_RUNTIME_DRIVER]
+ PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+ TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+ DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
+ MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+ ReportStatusCodeLib|MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+ DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+ DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
+ UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
+ BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
+ PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
+ QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
+
+[LibraryClasses.common.UEFI_DRIVER]
+ PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+ TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+ DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
+ MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+ ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+ DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+ DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
+ UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
+ PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
+
+[LibraryClasses.common.DXE_DRIVER]
+ PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+ TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+ MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+ ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+ UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+ DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+ DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
+ PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+ PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
+ QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
+ CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+ LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
+!ifdef $(SOURCE_DEBUG_ENABLE)
+ DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
+!endif
+ PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
+ MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+ QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
+
+[LibraryClasses.common.UEFI_APPLICATION]
+ PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+ TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+ MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+ ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+ DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+ DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
+ PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
+
+################################################################################
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform.
+#
+################################################################################
+[PcdsFeatureFlag]
+ gEfiMdeModulePkgTokenSpaceGuid.PcdHiiOsRuntimeSupport|FALSE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|TRUE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSupportUefiDecompress|FALSE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
+
+[PcdsFixedAtBuild]
+ gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
+ gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
+ gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x10
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+ gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
+!if $(NETWORK_TLS_ENABLE) == FALSE
+ # match PcdFlashNvStorageVariableSize purely for convenience
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
+!endif
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+ gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
+ gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
+!if $(NETWORK_TLS_ENABLE) == FALSE
+ # match PcdFlashNvStorageVariableSize purely for convenience
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x40000
+!endif
+!endif
+!if $(NETWORK_TLS_ENABLE) == TRUE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x80000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVolatileVariableSize|0x40000
+!endif
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
+
+ gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
+
+ # DEBUG_INIT 0x00000001 // Initialization
+ # DEBUG_WARN 0x00000002 // Warnings
+ # DEBUG_LOAD 0x00000004 // Load events
+ # DEBUG_FS 0x00000008 // EFI File system
+ # DEBUG_POOL 0x00000010 // Alloc & Free (pool)
+ # DEBUG_PAGE 0x00000020 // Alloc & Free (page)
+ # DEBUG_INFO 0x00000040 // Informational debug messages
+ # DEBUG_DISPATCH 0x00000080 // PEI/DXE/SMM Dispatchers
+ # DEBUG_VARIABLE 0x00000100 // Variable
+ # DEBUG_BM 0x00000400 // Boot Manager
+ # DEBUG_BLKIO 0x00001000 // BlkIo Driver
+ # DEBUG_NET 0x00004000 // SNP Driver
+ # DEBUG_UNDI 0x00010000 // UNDI Driver
+ # DEBUG_LOADFILE 0x00020000 // LoadFile
+ # DEBUG_EVENT 0x00080000 // Event messages
+ # DEBUG_GCD 0x00100000 // Global Coherency Database changes
+ # DEBUG_CACHE 0x00200000 // Memory range cachability changes
+ # DEBUG_VERBOSE 0x00400000 // Detailed debug messages that may
+ # // significantly impact boot performance
+ # DEBUG_ERROR 0x80000000 // Error
+ gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8000004F
+
+!ifdef $(SOURCE_DEBUG_ENABLE)
+ gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x17
+!else
+ gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
+!endif
+
+ # This PCD is used to set the base address of the PCI express hierarchy. It
+ # is only consulted when OVMF runs on Q35. In that case it is programmed into
+ # the PCIEXBAR register.
+ #
+ # On Q35 machine types that QEMU intends to support in the long term, QEMU
+ # never lets the RAM below 4 GB exceed 2816 MB.
+ gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xB0000000
+
+!ifdef $(SOURCE_DEBUG_ENABLE)
+ gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2
+!endif
+
+ #
+ # Network Pcds
+ #
+!include NetworkPkg/NetworkPcds.dsc.inc
+
+ # IRQs 5, 9, 10, 11 are level-triggered
+ gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
+
+ # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
+ gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
+
+################################################################################
+#
+# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
+#
+################################################################################
+
+[PcdsDynamicDefault]
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
+ gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|TRUE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable|FALSE
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId|0
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase|0x0
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize|0x0
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x800000000
+
+ gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
+
+ # Set video resolution for text setup.
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution|640
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution|480
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0208
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0
+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE
+
+ # Noexec settings for DXE.
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
+
+ # UefiCpuPkg PCDs related to initial AP bringup and general AP management.
+ gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64
+ gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds|50000
+
+ # Set memory encryption mask
+ gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
+
+ gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
+
+################################################################################
+#
+# Components Section - list of all EDK II Modules needed by this Platform.
+#
+################################################################################
+[Components]
+ OvmfPkg/ResetVector/ResetVector.inf
+
+ #
+ # SEC Phase modules
+ #
+ OvmfPkg/Sec/SecMain.inf {
+ <LibraryClasses>
+ NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+ }
+
+ #
+ # PEI Phase modules
+ #
+ MdeModulePkg/Core/Pei/PeiMain.inf
+ MdeModulePkg/Universal/PCD/Pei/Pcd.inf {
+ <LibraryClasses>
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ }
+ MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf {
+ <LibraryClasses>
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ }
+ MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
+ <LibraryClasses>
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ }
+ MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+
+ OvmfPkg/PlatformPei/PlatformPei.inf
+ UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+ UefiCpuPkg/CpuMpPei/CpuMpPei.inf
+
+ #
+ # DXE Phase modules
+ #
+ MdeModulePkg/Core/Dxe/DxeMain.inf {
+ <LibraryClasses>
+ NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+ DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+ }
+
+ MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+ MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
+ MdeModulePkg/Universal/PCD/Dxe/Pcd.inf {
+ <LibraryClasses>
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ }
+
+ MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
+
+ MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
+
+ MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
+ OvmfPkg/8259InterruptControllerDxe/8259.inf
+ UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
+ UefiCpuPkg/CpuDxe/CpuDxe.inf
+ OvmfPkg/8254TimerDxe/8254Timer.inf
+ OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
+ OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
+ MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
+ <LibraryClasses>
+ PciHostBridgeLib|OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
+ NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
+ }
+ MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
+ <LibraryClasses>
+ PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+ }
+ MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
+ MdeModulePkg/Universal/Metronome/Metronome.inf
+ PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+ MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
+ MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
+ <LibraryClasses>
+!ifdef $(CSM_ENABLE)
+ NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
+ NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
+!endif
+ }
+ MdeModulePkg/Logo/LogoDxe.inf
+ MdeModulePkg/Application/UiApp/UiApp.inf {
+ <LibraryClasses>
+ NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
+ NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
+ NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
+!ifdef $(CSM_ENABLE)
+ NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
+ NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
+!endif
+ }
+ OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
+ OvmfPkg/XenBusDxe/XenBusDxe.inf
+ OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+ MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
+ MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
+ MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
+ MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
+ MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
+ MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf {
+ <LibraryClasses>
+ PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+ }
+ MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+ MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf {
+ <LibraryClasses>
+ DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ }
+ MdeModulePkg/Universal/PrintDxe/PrintDxe.inf
+ MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
+ MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
+ MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
+ MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
+ FatPkg/EnhancedFatDxe/Fat.inf
+ MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
+ MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
+ MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
+ OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+ MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
+ MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
+ MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
+ MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
+ MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+ MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
+ MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
+
+ OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
+ OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
+
+ #
+ # ISA Support
+ #
+ OvmfPkg/SioBusDxe/SioBusDxe.inf
+ MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
+ MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
+
+ #
+ # SMBIOS Support
+ #
+ MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
+ <LibraryClasses>
+ NULL|OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf
+ }
+ OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
+
+ #
+ # ACPI Support
+ #
+ MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+ OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+ OvmfPkg/AcpiTables/AcpiTables.inf
+ MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
+ MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+ MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
+
+ #
+ # Network Support
+ #
+!include NetworkPkg/NetworkComponents.dsc.inc
+
+!if $(NETWORK_TLS_ENABLE) == TRUE
+ NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf {
+ <LibraryClasses>
+ NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
+ }
+!endif
+
+ #
+ # Usb Support
+ #
+ MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
+ MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
+ MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
+ MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
+ MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+ MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
+
+!ifdef $(CSM_ENABLE)
+ OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
+ <LibraryClasses>
+ PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+ }
+ OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
+ OvmfPkg/Csm/Csm16/Csm16.inf
+!endif
+
+!if $(TOOL_CHAIN_TAG) != "XCODE5"
+ ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
+ <PcdsFixedAtBuild>
+ gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+ }
+!endif
+ ShellPkg/Application/Shell/Shell.inf {
+ <LibraryClasses>
+ ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
+ NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
+!if $(NETWORK_IP6_ENABLE) == TRUE
+ NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
+!endif
+ HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
+ PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+ BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
+
+ <PcdsFixedAtBuild>
+ gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
+ gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+ gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
+ }
+
+ OvmfPkg/PlatformDxe/Platform.inf
+ OvmfPkg/AmdSevDxe/AmdSevDxe.inf
+ OvmfPkg/IoMmuDxe/IoMmuDxe.inf
+
+ #
+ # Variable driver stack (non-SMM)
+ #
+ OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+ OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
+ <LibraryClasses>
+ PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
+ }
+ MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+ <LibraryClasses>
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
new file mode 100644
index 0000000000..f59647fd14
--- /dev/null
+++ b/OvmfPkg/OvmfXen.fdf
@@ -0,0 +1,439 @@
+## @file
+# Open Virtual Machine Firmware: FDF
+#
+# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
+# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+################################################################################
+
+[Defines]
+!include OvmfPkg.fdf.inc
+
+#
+# Build the variable store and the firmware code as one unified flash device
+# image.
+#
+[FD.OVMF]
+BaseAddress = $(FW_BASE_ADDRESS)
+Size = $(FW_SIZE)
+ErasePolarity = 1
+BlockSize = $(BLOCK_SIZE)
+NumBlocks = $(FW_BLOCKS)
+
+!include VarStore.fdf.inc
+
+$(VARS_SIZE)|$(FVMAIN_SIZE)
+FV = FVMAIN_COMPACT
+
+$(SECFV_OFFSET)|$(SECFV_SIZE)
+FV = SECFV
+
+#
+# Build the variable store and the firmware code as separate flash device
+# images.
+#
+[FD.OVMF_VARS]
+BaseAddress = $(FW_BASE_ADDRESS)
+Size = $(VARS_SIZE)
+ErasePolarity = 1
+BlockSize = $(BLOCK_SIZE)
+NumBlocks = $(VARS_BLOCKS)
+
+!include VarStore.fdf.inc
+
+[FD.OVMF_CODE]
+BaseAddress = $(CODE_BASE_ADDRESS)
+Size = $(CODE_SIZE)
+ErasePolarity = 1
+BlockSize = $(BLOCK_SIZE)
+NumBlocks = $(CODE_BLOCKS)
+
+0x00000000|$(FVMAIN_SIZE)
+FV = FVMAIN_COMPACT
+
+$(FVMAIN_SIZE)|$(SECFV_SIZE)
+FV = SECFV
+
+################################################################################
+
+[FD.MEMFD]
+BaseAddress = $(MEMFD_BASE_ADDRESS)
+Size = 0xB00000
+ErasePolarity = 1
+BlockSize = 0x10000
+NumBlocks = 0xB0
+
+0x000000|0x006000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
+
+0x006000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
+
+0x007000|0x001000
+gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
+
+0x010000|0x010000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
+
+0x020000|0x0E0000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
+FV = PEIFV
+
+0x100000|0xA00000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
+FV = DXEFV
+
+################################################################################
+
+[FV.SECFV]
+FvNameGuid = 763BED0D-DE9F-48F5-81F1-3E90E1B1A015
+BlockSize = 0x1000
+FvAlignment = 16
+ERASE_POLARITY = 1
+MEMORY_MAPPED = TRUE
+STICKY_WRITE = TRUE
+LOCK_CAP = TRUE
+LOCK_STATUS = TRUE
+WRITE_DISABLED_CAP = TRUE
+WRITE_ENABLED_CAP = TRUE
+WRITE_STATUS = TRUE
+WRITE_LOCK_CAP = TRUE
+WRITE_LOCK_STATUS = TRUE
+READ_DISABLED_CAP = TRUE
+READ_ENABLED_CAP = TRUE
+READ_STATUS = TRUE
+READ_LOCK_CAP = TRUE
+READ_LOCK_STATUS = TRUE
+
+#
+# SEC Phase modules
+#
+# The code in this FV handles the initial firmware startup, and
+# decompresses the PEI and DXE FVs which handles the rest of the boot sequence.
+#
+INF OvmfPkg/Sec/SecMain.inf
+
+INF RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
+
+################################################################################
+[FV.PEIFV]
+FvNameGuid = 6938079B-B503-4E3D-9D24-B28337A25806
+BlockSize = 0x10000
+FvAlignment = 16
+ERASE_POLARITY = 1
+MEMORY_MAPPED = TRUE
+STICKY_WRITE = TRUE
+LOCK_CAP = TRUE
+LOCK_STATUS = TRUE
+WRITE_DISABLED_CAP = TRUE
+WRITE_ENABLED_CAP = TRUE
+WRITE_STATUS = TRUE
+WRITE_LOCK_CAP = TRUE
+WRITE_LOCK_STATUS = TRUE
+READ_DISABLED_CAP = TRUE
+READ_ENABLED_CAP = TRUE
+READ_STATUS = TRUE
+READ_LOCK_CAP = TRUE
+READ_LOCK_STATUS = TRUE
+
+APRIORI PEI {
+ INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
+}
+
+#
+# PEI Phase modules
+#
+INF MdeModulePkg/Core/Pei/PeiMain.inf
+INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
+INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
+INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
+INF OvmfPkg/PlatformPei/PlatformPei.inf
+INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
+
+################################################################################
+
+[FV.DXEFV]
+FvForceRebase = FALSE
+FvNameGuid = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
+BlockSize = 0x10000
+FvAlignment = 16
+ERASE_POLARITY = 1
+MEMORY_MAPPED = TRUE
+STICKY_WRITE = TRUE
+LOCK_CAP = TRUE
+LOCK_STATUS = TRUE
+WRITE_DISABLED_CAP = TRUE
+WRITE_ENABLED_CAP = TRUE
+WRITE_STATUS = TRUE
+WRITE_LOCK_CAP = TRUE
+WRITE_LOCK_STATUS = TRUE
+READ_DISABLED_CAP = TRUE
+READ_ENABLED_CAP = TRUE
+READ_STATUS = TRUE
+READ_LOCK_CAP = TRUE
+READ_LOCK_STATUS = TRUE
+
+APRIORI DXE {
+ INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
+ INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+ INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
+ INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+}
+
+#
+# DXE Phase modules
+#
+INF MdeModulePkg/Core/Dxe/DxeMain.inf
+
+INF MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+INF MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
+INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+
+INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
+INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
+INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
+INF OvmfPkg/8259InterruptControllerDxe/8259.inf
+INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
+INF UefiCpuPkg/CpuDxe/CpuDxe.inf
+INF OvmfPkg/8254TimerDxe/8254Timer.inf
+INF OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
+INF OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
+INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
+INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
+INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
+INF MdeModulePkg/Universal/Metronome/Metronome.inf
+INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+
+INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
+INF OvmfPkg/XenBusDxe/XenBusDxe.inf
+INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+
+INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
+INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
+INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
+INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
+INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
+INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
+INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
+INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+INF MdeModulePkg/Application/UiApp/UiApp.inf
+INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
+INF MdeModulePkg/Universal/PrintDxe/PrintDxe.inf
+INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
+INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
+INF MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
+INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
+INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
+INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
+INF OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
+INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
+INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
+INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
+INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
+INF MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
+
+INF OvmfPkg/SioBusDxe/SioBusDxe.inf
+!ifndef $(SOURCE_DEBUG_ENABLE)
+INF MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
+!endif
+INF MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
+
+INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
+INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
+
+INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+INF OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+INF RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
+INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
+INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
+
+INF FatPkg/EnhancedFatDxe/Fat.inf
+INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
+
+!if $(TOOL_CHAIN_TAG) != "XCODE5"
+INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
+!endif
+INF ShellPkg/Application/Shell/Shell.inf
+
+INF MdeModulePkg/Logo/LogoDxe.inf
+
+#
+# Network modules
+#
+!if $(E1000_ENABLE)
+ FILE DRIVER = 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 {
+ SECTION PE32 = Intel3.5/EFIX64/E3522X2.EFI
+ }
+!endif
+!include NetworkPkg/Network.fdf.inc
+
+#
+# Usb Support
+#
+INF MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
+INF MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
+INF MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
+INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
+INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+INF MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
+
+!ifdef $(CSM_ENABLE)
+INF OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf
+INF OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
+INF RuleOverride=CSM OvmfPkg/Csm/Csm16/Csm16.inf
+!endif
+
+INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
+INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
+INF OvmfPkg/PlatformDxe/Platform.inf
+INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
+INF OvmfPkg/IoMmuDxe/IoMmuDxe.inf
+
+#
+# Variable driver stack (non-SMM)
+#
+INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+INF OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
+INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+
+################################################################################
+
+[FV.FVMAIN_COMPACT]
+FvNameGuid = 48DB5E17-707C-472D-91CD-1613E7EF51B0
+FvAlignment = 16
+ERASE_POLARITY = 1
+MEMORY_MAPPED = TRUE
+STICKY_WRITE = TRUE
+LOCK_CAP = TRUE
+LOCK_STATUS = TRUE
+WRITE_DISABLED_CAP = TRUE
+WRITE_ENABLED_CAP = TRUE
+WRITE_STATUS = TRUE
+WRITE_LOCK_CAP = TRUE
+WRITE_LOCK_STATUS = TRUE
+READ_DISABLED_CAP = TRUE
+READ_ENABLED_CAP = TRUE
+READ_STATUS = TRUE
+READ_LOCK_CAP = TRUE
+READ_LOCK_STATUS = TRUE
+
+FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
+ SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED = TRUE {
+ #
+ # These firmware volumes will have files placed in them uncompressed,
+ # and then both firmware volumes will be compressed in a single
+ # compression operation in order to achieve better overall compression.
+ #
+ SECTION FV_IMAGE = PEIFV
+ SECTION FV_IMAGE = DXEFV
+ }
+ }
+
+!include DecomprScratchEnd.fdf.inc
+
+################################################################################
+
+[Rule.Common.SEC]
+ FILE SEC = $(NAMED_GUID) {
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING ="$(MODULE_NAME)" Optional
+ VERSION STRING ="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.PEI_CORE]
+ FILE PEI_CORE = $(NAMED_GUID) {
+ PE32 PE32 Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING ="$(MODULE_NAME)" Optional
+ VERSION STRING ="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.PEIM]
+ FILE PEIM = $(NAMED_GUID) {
+ PEI_DEPEX PEI_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
+ PE32 PE32 Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.DXE_CORE]
+ FILE DXE_CORE = $(NAMED_GUID) {
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.DXE_DRIVER]
+ FILE DRIVER = $(NAMED_GUID) {
+ DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ RAW ACPI Optional |.acpi
+ RAW ASL Optional |.aml
+ }
+
+[Rule.Common.DXE_RUNTIME_DRIVER]
+ FILE DRIVER = $(NAMED_GUID) {
+ DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.UEFI_DRIVER]
+ FILE DRIVER = $(NAMED_GUID) {
+ DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.UEFI_DRIVER.BINARY]
+ FILE DRIVER = $(NAMED_GUID) {
+ DXE_DEPEX DXE_DEPEX Optional |.depex
+ PE32 PE32 |.efi
+ UI STRING="$(MODULE_NAME)" Optional
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.UEFI_APPLICATION]
+ FILE APPLICATION = $(NAMED_GUID) {
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.UEFI_APPLICATION.BINARY]
+ FILE APPLICATION = $(NAMED_GUID) {
+ PE32 PE32 |.efi
+ UI STRING="$(MODULE_NAME)" Optional
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.USER_DEFINED.ACPITABLE]
+ FILE FREEFORM = $(NAMED_GUID) {
+ RAW ACPI |.acpi
+ RAW ASL |.aml
+ }
+
+[Rule.Common.USER_DEFINED.CSM]
+ FILE FREEFORM = $(NAMED_GUID) {
+ RAW BIN |.bin
+ }
+
+[Rule.Common.SEC.RESET_VECTOR]
+ FILE RAW = $(NAMED_GUID) {
+ RAW BIN Align = 16 |.bin
+ }
diff --git a/Maintainers.txt b/Maintainers.txt
index 0298010809..98f6d828eb 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -372,6 +372,7 @@ F: OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
F: OvmfPkg/Library/XenConsoleSerialPortLib/
F: OvmfPkg/Library/XenHypercallLib/
F: OvmfPkg/Library/XenIoMmioLib/
+F: OvmfPkg/OvmfXen.*
F: OvmfPkg/PlatformPei/MemDetect.c
F: OvmfPkg/PlatformPei/Platform.*
F: OvmfPkg/PlatformPei/Xen.*
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 02/35] OvmfPkg: Create platform OvmfXen
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 02/35] OvmfPkg: Create platform OvmfXen Anthony PERARD
@ 2019-07-30 9:13 ` Laszlo Ersek
0 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 9:13 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Jordan Justen
On 07/29/19 17:39, Anthony PERARD wrote:
> OvmfXen is a copy of OvmfX64, removing VirtIO and some SMM.
>
> This new platform will be changed to make it works on two types of Xen
> guest: HVM and PVH.
>
> Compare to OvmfX64, this patch:
>
> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
> - removed: VirtioLib class resolution
> - removed: all UEFI_DRIVER modules for virtio devices
> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
> - removed: Everything related to SMM_REQUIRE==true
> - removed: Everything related to SECURE_BOOT_ENABLE==true
> - removed: Everything related to TPM2_ENABLE==true
> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
> - changed: default FD_SIZE_IN_KB to 2M.
> - reverted d272449d9e1e, "OvmfPkg: raise DXEFV size to 11 MB"
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - rebased
> - Update Maintainers.txt
>
> v3:
> - rebased, SPDX + 8259/8254 changes
>
> OvmfPkg/OvmfXen.dsc | 729 ++++++++++++++++++++++++++++++++++++++++++++
> OvmfPkg/OvmfXen.fdf | 439 ++++++++++++++++++++++++++
> Maintainers.txt | 1 +
> 3 files changed, 1169 insertions(+)
> create mode 100644 OvmfPkg/OvmfXen.dsc
> create mode 100644 OvmfPkg/OvmfXen.fdf
[...]
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 0298010809..98f6d828eb 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -372,6 +372,7 @@ F: OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> F: OvmfPkg/Library/XenConsoleSerialPortLib/
> F: OvmfPkg/Library/XenHypercallLib/
> F: OvmfPkg/Library/XenIoMmioLib/
> +F: OvmfPkg/OvmfXen.*
> F: OvmfPkg/PlatformPei/MemDetect.c
> F: OvmfPkg/PlatformPei/Platform.*
> F: OvmfPkg/PlatformPei/Xen.*
>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 03/35] OvmfPkg: Introduce XenResetVector
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 01/35] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 02/35] OvmfPkg: Create platform OvmfXen Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 9:16 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 04/35] OvmfPkg: Introduce XenPlatformPei Anthony PERARD
` (33 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Introduce XenResetVector, a copy of OvmfPkg/ResetVector, with one
changes:
- SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
Xen copies the OVMF code to RAM, there is no need to disable cache.
This new module will later be modified to add a new entry point, more
detail in a following commit "OvmfPkg/XenResetVector: Add new entry point
for Xen PVH"
Value FILE_GUID of XenResetVector have not changed compare to ResetVector
because it is a special value (gEfiFirmwareVolumeTopFileGuid).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- Update Maintainers.txt
v3:
- Added gEfiFirmwareVolumeTopFileGuid to the commit message.
- rebased: SPDX
OvmfPkg/OvmfXen.dsc | 2 +-
OvmfPkg/OvmfXen.fdf | 2 +-
OvmfPkg/XenResetVector/XenResetVector.inf | 38 +++++
Maintainers.txt | 1 +
.../XenResetVector/Ia16/Real16ToFlat32.asm | 134 ++++++++++++++++
OvmfPkg/XenResetVector/Ia32/PageTables64.asm | 149 ++++++++++++++++++
OvmfPkg/XenResetVector/XenResetVector.nasmb | 68 ++++++++
7 files changed, 392 insertions(+), 2 deletions(-)
create mode 100644 OvmfPkg/XenResetVector/XenResetVector.inf
create mode 100644 OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
create mode 100644 OvmfPkg/XenResetVector/Ia32/PageTables64.asm
create mode 100644 OvmfPkg/XenResetVector/XenResetVector.nasmb
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index f224ac32b4..1a0e59f0cc 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -495,7 +495,7 @@ [PcdsDynamicDefault]
#
################################################################################
[Components]
- OvmfPkg/ResetVector/ResetVector.inf
+ OvmfPkg/XenResetVector/XenResetVector.inf
#
# SEC Phase modules
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index f59647fd14..6fc8479aae 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -118,7 +118,7 @@ [FV.SECFV]
#
INF OvmfPkg/Sec/SecMain.inf
-INF RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
+INF RuleOverride=RESET_VECTOR OvmfPkg/XenResetVector/XenResetVector.inf
################################################################################
[FV.PEIFV]
diff --git a/OvmfPkg/XenResetVector/XenResetVector.inf b/OvmfPkg/XenResetVector/XenResetVector.inf
new file mode 100644
index 0000000000..097fc9b5b4
--- /dev/null
+++ b/OvmfPkg/XenResetVector/XenResetVector.inf
@@ -0,0 +1,38 @@
+## @file
+# Reset Vector
+#
+# Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION = 0x00010005
+ BASE_NAME = XenResetVector
+ FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
+ MODULE_TYPE = SEC
+ VERSION_STRING = 1.1
+
+#
+# The following information is for reference only and not required by the build tools.
+#
+# VALID_ARCHITECTURES = IA32 X64
+#
+
+[Sources]
+ XenResetVector.nasmb
+
+[Packages]
+ OvmfPkg/OvmfPkg.dec
+ MdePkg/MdePkg.dec
+ UefiCpuPkg/UefiCpuPkg.dec
+
+[BuildOptions]
+ *_*_IA32_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
+ *_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
+
+[Pcd]
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
diff --git a/Maintainers.txt b/Maintainers.txt
index 98f6d828eb..34bdb275b4 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -380,6 +380,7 @@ F: OvmfPkg/SmbiosPlatformDxe/*Xen.c
F: OvmfPkg/XenBusDxe/
F: OvmfPkg/XenIoPciDxe/
F: OvmfPkg/XenPvBlkDxe/
+F: OvmfPkg/XenResetVector/
R: Anthony Perard <anthony.perard@citrix.com>
R: Julien Grall <julien.grall@arm.com>
diff --git a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
new file mode 100644
index 0000000000..5c329bfaea
--- /dev/null
+++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
@@ -0,0 +1,134 @@
+;------------------------------------------------------------------------------
+; @file
+; Transition from 16 bit real mode into 32 bit flat protected mode
+;
+; Copyright (c) 2008 - 2010, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+%define SEC_DEFAULT_CR0 0x00000023
+%define SEC_DEFAULT_CR4 0x640
+
+BITS 16
+
+;
+; Modified: EAX, EBX
+;
+; @param[out] DS Selector allowing flat access to all addresses
+; @param[out] ES Selector allowing flat access to all addresses
+; @param[out] FS Selector allowing flat access to all addresses
+; @param[out] GS Selector allowing flat access to all addresses
+; @param[out] SS Selector allowing flat access to all addresses
+;
+TransitionFromReal16To32BitFlat:
+
+ debugShowPostCode POSTCODE_16BIT_MODE
+
+ cli
+
+ mov bx, 0xf000
+ mov ds, bx
+
+ mov bx, ADDR16_OF(gdtr)
+
+o32 lgdt [cs:bx]
+
+ mov eax, SEC_DEFAULT_CR0
+ mov cr0, eax
+
+ jmp LINEAR_CODE_SEL:dword ADDR_OF(jumpTo32BitAndLandHere)
+BITS 32
+jumpTo32BitAndLandHere:
+
+ mov eax, SEC_DEFAULT_CR4
+ mov cr4, eax
+
+ debugShowPostCode POSTCODE_32BIT_MODE
+
+ mov ax, LINEAR_SEL
+ mov ds, ax
+ mov es, ax
+ mov fs, ax
+ mov gs, ax
+ mov ss, ax
+
+ OneTimeCallRet TransitionFromReal16To32BitFlat
+
+ALIGN 2
+
+gdtr:
+ dw GDT_END - GDT_BASE - 1 ; GDT limit
+ dd ADDR_OF(GDT_BASE)
+
+ALIGN 16
+
+;
+; Macros for GDT entries
+;
+
+%define PRESENT_FLAG(p) (p << 7)
+%define DPL(dpl) (dpl << 5)
+%define SYSTEM_FLAG(s) (s << 4)
+%define DESC_TYPE(t) (t)
+
+; Type: data, expand-up, writable, accessed
+%define DATA32_TYPE 3
+
+; Type: execute, readable, expand-up, accessed
+%define CODE32_TYPE 0xb
+
+; Type: execute, readable, expand-up, accessed
+%define CODE64_TYPE 0xb
+
+%define GRANULARITY_FLAG(g) (g << 7)
+%define DEFAULT_SIZE32(d) (d << 6)
+%define CODE64_FLAG(l) (l << 5)
+%define UPPER_LIMIT(l) (l)
+
+;
+; The Global Descriptor Table (GDT)
+;
+
+GDT_BASE:
+; null descriptor
+NULL_SEL equ $-GDT_BASE
+ DW 0 ; limit 15:0
+ DW 0 ; base 15:0
+ DB 0 ; base 23:16
+ DB 0 ; sys flag, dpl, type
+ DB 0 ; limit 19:16, flags
+ DB 0 ; base 31:24
+
+; linear data segment descriptor
+LINEAR_SEL equ $-GDT_BASE
+ DW 0xffff ; limit 15:0
+ DW 0 ; base 15:0
+ DB 0 ; base 23:16
+ DB PRESENT_FLAG(1)|DPL(0)|SYSTEM_FLAG(1)|DESC_TYPE(DATA32_TYPE)
+ DB GRANULARITY_FLAG(1)|DEFAULT_SIZE32(1)|CODE64_FLAG(0)|UPPER_LIMIT(0xf)
+ DB 0 ; base 31:24
+
+; linear code segment descriptor
+LINEAR_CODE_SEL equ $-GDT_BASE
+ DW 0xffff ; limit 15:0
+ DW 0 ; base 15:0
+ DB 0 ; base 23:16
+ DB PRESENT_FLAG(1)|DPL(0)|SYSTEM_FLAG(1)|DESC_TYPE(CODE32_TYPE)
+ DB GRANULARITY_FLAG(1)|DEFAULT_SIZE32(1)|CODE64_FLAG(0)|UPPER_LIMIT(0xf)
+ DB 0 ; base 31:24
+
+%ifdef ARCH_X64
+; linear code (64-bit) segment descriptor
+LINEAR_CODE64_SEL equ $-GDT_BASE
+ DW 0xffff ; limit 15:0
+ DW 0 ; base 15:0
+ DB 0 ; base 23:16
+ DB PRESENT_FLAG(1)|DPL(0)|SYSTEM_FLAG(1)|DESC_TYPE(CODE64_TYPE)
+ DB GRANULARITY_FLAG(1)|DEFAULT_SIZE32(0)|CODE64_FLAG(1)|UPPER_LIMIT(0xf)
+ DB 0 ; base 31:24
+%endif
+
+GDT_END:
+
diff --git a/OvmfPkg/XenResetVector/Ia32/PageTables64.asm b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
new file mode 100644
index 0000000000..9f1c0e2259
--- /dev/null
+++ b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
@@ -0,0 +1,149 @@
+;------------------------------------------------------------------------------
+; @file
+; Sets the CR3 register for 64-bit paging
+;
+; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+BITS 32
+
+%define PAGE_PRESENT 0x01
+%define PAGE_READ_WRITE 0x02
+%define PAGE_USER_SUPERVISOR 0x04
+%define PAGE_WRITE_THROUGH 0x08
+%define PAGE_CACHE_DISABLE 0x010
+%define PAGE_ACCESSED 0x020
+%define PAGE_DIRTY 0x040
+%define PAGE_PAT 0x080
+%define PAGE_GLOBAL 0x0100
+%define PAGE_2M_MBO 0x080
+%define PAGE_2M_PAT 0x01000
+
+%define PAGE_2M_PDE_ATTR (PAGE_2M_MBO + \
+ PAGE_ACCESSED + \
+ PAGE_DIRTY + \
+ PAGE_READ_WRITE + \
+ PAGE_PRESENT)
+
+%define PAGE_PDP_ATTR (PAGE_ACCESSED + \
+ PAGE_READ_WRITE + \
+ PAGE_PRESENT)
+
+; Check if Secure Encrypted Virtualization (SEV) feature is enabled
+;
+; If SEV is enabled then EAX will be at least 32
+; If SEV is disabled then EAX will be zero.
+;
+CheckSevFeature:
+ ; Check if we have a valid (0x8000_001F) CPUID leaf
+ mov eax, 0x80000000
+ cpuid
+
+ ; This check should fail on Intel or Non SEV AMD CPUs. In future if
+ ; Intel CPUs supports this CPUID leaf then we are guranteed to have exact
+ ; same bit definition.
+ cmp eax, 0x8000001f
+ jl NoSev
+
+ ; Check for memory encryption feature:
+ ; CPUID Fn8000_001F[EAX] - Bit 1
+ ;
+ mov eax, 0x8000001f
+ cpuid
+ bt eax, 1
+ jnc NoSev
+
+ ; Check if memory encryption is enabled
+ ; MSR_0xC0010131 - Bit 0 (SEV enabled)
+ mov ecx, 0xc0010131
+ rdmsr
+ bt eax, 0
+ jnc NoSev
+
+ ; Get pte bit position to enable memory encryption
+ ; CPUID Fn8000_001F[EBX] - Bits 5:0
+ ;
+ mov eax, ebx
+ and eax, 0x3f
+ jmp SevExit
+
+NoSev:
+ xor eax, eax
+
+SevExit:
+ OneTimeCallRet CheckSevFeature
+
+;
+; Modified: EAX, EBX, ECX, EDX
+;
+SetCr3ForPageTables64:
+
+ OneTimeCall CheckSevFeature
+ xor edx, edx
+ test eax, eax
+ jz SevNotActive
+
+ ; If SEV is enabled, C-bit is always above 31
+ sub eax, 32
+ bts edx, eax
+
+SevNotActive:
+
+ ;
+ ; For OVMF, build some initial page tables at
+ ; PcdOvmfSecPageTablesBase - (PcdOvmfSecPageTablesBase + 0x6000).
+ ;
+ ; This range should match with PcdOvmfSecPageTablesSize which is
+ ; declared in the FDF files.
+ ;
+ ; At the end of PEI, the pages tables will be rebuilt into a
+ ; more permanent location by DxeIpl.
+ ;
+
+ mov ecx, 6 * 0x1000 / 4
+ xor eax, eax
+clearPageTablesMemoryLoop:
+ mov dword[ecx * 4 + PT_ADDR (0) - 4], eax
+ loop clearPageTablesMemoryLoop
+
+ ;
+ ; Top level Page Directory Pointers (1 * 512GB entry)
+ ;
+ mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDP_ATTR
+ mov dword[PT_ADDR (4)], edx
+
+ ;
+ ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
+ ;
+ mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + PAGE_PDP_ATTR
+ mov dword[PT_ADDR (0x1004)], edx
+ mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) + PAGE_PDP_ATTR
+ mov dword[PT_ADDR (0x100C)], edx
+ mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) + PAGE_PDP_ATTR
+ mov dword[PT_ADDR (0x1014)], edx
+ mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) + PAGE_PDP_ATTR
+ mov dword[PT_ADDR (0x101C)], edx
+
+ ;
+ ; Page Table Entries (2048 * 2MB entries => 4GB)
+ ;
+ mov ecx, 0x800
+pageTableEntriesLoop:
+ mov eax, ecx
+ dec eax
+ shl eax, 21
+ add eax, PAGE_2M_PDE_ATTR
+ mov [ecx * 8 + PT_ADDR (0x2000 - 8)], eax
+ mov [(ecx * 8 + PT_ADDR (0x2000 - 8)) + 4], edx
+ loop pageTableEntriesLoop
+
+ ;
+ ; Set CR3 now that the paging structures are available
+ ;
+ mov eax, PT_ADDR (0)
+ mov cr3, eax
+
+ OneTimeCallRet SetCr3ForPageTables64
diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
new file mode 100644
index 0000000000..89a4b08bc3
--- /dev/null
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -0,0 +1,68 @@
+;------------------------------------------------------------------------------
+; @file
+; This file includes all other code files to assemble the reset vector code
+;
+; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+;
+; If neither ARCH_IA32 nor ARCH_X64 are defined, then try to include
+; Base.h to use the C pre-processor to determine the architecture.
+;
+%ifndef ARCH_IA32
+ %ifndef ARCH_X64
+ #include <Base.h>
+ #if defined (MDE_CPU_IA32)
+ %define ARCH_IA32
+ #elif defined (MDE_CPU_X64)
+ %define ARCH_X64
+ #endif
+ %endif
+%endif
+
+%ifdef ARCH_IA32
+ %ifdef ARCH_X64
+ %error "Only one of ARCH_IA32 or ARCH_X64 can be defined."
+ %endif
+%elifdef ARCH_X64
+%else
+ %error "Either ARCH_IA32 or ARCH_X64 must be defined."
+%endif
+
+%include "CommonMacros.inc"
+
+%include "PostCodes.inc"
+
+%ifdef DEBUG_PORT80
+ %include "Port80Debug.asm"
+%elifdef DEBUG_SERIAL
+ %include "SerialDebug.asm"
+%else
+ %include "DebugDisabled.asm"
+%endif
+
+%include "Ia32/SearchForBfvBase.asm"
+%include "Ia32/SearchForSecEntry.asm"
+
+%ifdef ARCH_X64
+ #include <AutoGen.h>
+
+ %if (FixedPcdGet32 (PcdOvmfSecPageTablesSize) != 0x6000)
+ %error "This implementation inherently depends on PcdOvmfSecPageTablesSize"
+ %endif
+
+ %define PT_ADDR(Offset) (FixedPcdGet32 (PcdOvmfSecPageTablesBase) + (Offset))
+%include "Ia32/Flat32ToFlat64.asm"
+%include "Ia32/PageTables64.asm"
+%endif
+
+%include "Ia16/Real16ToFlat32.asm"
+%include "Ia16/Init16.asm"
+
+%include "Main.asm"
+
+%include "Ia16/ResetVectorVtf0.asm"
+
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 03/35] OvmfPkg: Introduce XenResetVector
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 03/35] OvmfPkg: Introduce XenResetVector Anthony PERARD
@ 2019-07-30 9:16 ` Laszlo Ersek
0 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 9:16 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Jordan Justen
On 07/29/19 17:39, Anthony PERARD wrote:
> Introduce XenResetVector, a copy of OvmfPkg/ResetVector, with one
> changes:
> - SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
>
> Xen copies the OVMF code to RAM, there is no need to disable cache.
>
> This new module will later be modified to add a new entry point, more
> detail in a following commit "OvmfPkg/XenResetVector: Add new entry point
> for Xen PVH"
>
> Value FILE_GUID of XenResetVector have not changed compare to ResetVector
> because it is a special value (gEfiFirmwareVolumeTopFileGuid).
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - Update Maintainers.txt
>
> v3:
> - Added gEfiFirmwareVolumeTopFileGuid to the commit message.
> - rebased: SPDX
>
> OvmfPkg/OvmfXen.dsc | 2 +-
> OvmfPkg/OvmfXen.fdf | 2 +-
> OvmfPkg/XenResetVector/XenResetVector.inf | 38 +++++
> Maintainers.txt | 1 +
> .../XenResetVector/Ia16/Real16ToFlat32.asm | 134 ++++++++++++++++
> OvmfPkg/XenResetVector/Ia32/PageTables64.asm | 149 ++++++++++++++++++
> OvmfPkg/XenResetVector/XenResetVector.nasmb | 68 ++++++++
> 7 files changed, 392 insertions(+), 2 deletions(-)
> create mode 100644 OvmfPkg/XenResetVector/XenResetVector.inf
> create mode 100644 OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> create mode 100644 OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> create mode 100644 OvmfPkg/XenResetVector/XenResetVector.nasmb
[...]
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 98f6d828eb..34bdb275b4 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -380,6 +380,7 @@ F: OvmfPkg/SmbiosPlatformDxe/*Xen.c
> F: OvmfPkg/XenBusDxe/
> F: OvmfPkg/XenIoPciDxe/
> F: OvmfPkg/XenPvBlkDxe/
> +F: OvmfPkg/XenResetVector/
> R: Anthony Perard <anthony.perard@citrix.com>
> R: Julien Grall <julien.grall@arm.com>
>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 04/35] OvmfPkg: Introduce XenPlatformPei
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (2 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 03/35] OvmfPkg: Introduce XenResetVector Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 9:21 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 05/35] OvmfPkg/OvmfXen: Creating an ELF header Anthony PERARD
` (32 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some
of QEMU specific initialization, Xen does not support QemuFwCfg.
This new module will be adjusted to accommodate Xen PVH.
fw_cfg dependents that have been removed, which are dynamically skipped
when running PlatformPei on Xen:
- GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
(experimental) "opt/ovmf/X-PciMmio64Mb" file
- GetFirstNonAddress(): honoring the hotplug DIMM area
("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO
aperture
- NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
PcdSetNxForStack are left constant FALSE (not set dynamically from
fw_cfg "opt/ovmf/PcdXxxx")
- MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
PcdCpuMaxLogicalProcessorNumber is used intact and
PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
- InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
consulting "etc/system-states" via QemuFwCfgS3Enabled()).
- InstallFeatureControlCallback(): the feature control MSR is not set
from "etc/msr_feature_control"
(also removed FeatureControl.c as there is nothing been executed)
Also removed:
- SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
assumed FALSE) in PublishPeiMemory(),
- QemuInitializeRam() entirely,
Xen related changes:
- Have removed the module variable mXen, as it should be always true.
- Have the platform PEI initialization fails if Xen has not been
detected.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- replace the other EFI_D_ by DEBUG_.
- Update Maintainers.txt
- fix one trailing whitespace
v3:
- fix coding style in new code
(use DEBUG_xxx, add ASSERT before CpuDeadLoop)
- rebased, SPDX
OvmfPkg/OvmfXen.dsc | 2 +-
OvmfPkg/OvmfXen.fdf | 2 +-
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 96 +++++
OvmfPkg/XenPlatformPei/Cmos.h | 52 +++
OvmfPkg/XenPlatformPei/Platform.h | 108 ++++++
OvmfPkg/XenPlatformPei/Xen.h | 39 ++
OvmfPkg/XenPlatformPei/AmdSev.c | 64 ++++
OvmfPkg/XenPlatformPei/ClearCache.c | 112 ++++++
OvmfPkg/XenPlatformPei/Cmos.c | 60 +++
OvmfPkg/XenPlatformPei/Fv.c | 76 ++++
OvmfPkg/XenPlatformPei/MemDetect.c | 421 ++++++++++++++++++++
OvmfPkg/XenPlatformPei/Platform.c | 444 ++++++++++++++++++++++
OvmfPkg/XenPlatformPei/Xen.c | 219 +++++++++++
Maintainers.txt | 1 +
14 files changed, 1694 insertions(+), 2 deletions(-)
create mode 100644 OvmfPkg/XenPlatformPei/XenPlatformPei.inf
create mode 100644 OvmfPkg/XenPlatformPei/Cmos.h
create mode 100644 OvmfPkg/XenPlatformPei/Platform.h
create mode 100644 OvmfPkg/XenPlatformPei/Xen.h
create mode 100644 OvmfPkg/XenPlatformPei/AmdSev.c
create mode 100644 OvmfPkg/XenPlatformPei/ClearCache.c
create mode 100644 OvmfPkg/XenPlatformPei/Cmos.c
create mode 100644 OvmfPkg/XenPlatformPei/Fv.c
create mode 100644 OvmfPkg/XenPlatformPei/MemDetect.c
create mode 100644 OvmfPkg/XenPlatformPei/Platform.c
create mode 100644 OvmfPkg/XenPlatformPei/Xen.c
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 1a0e59f0cc..7619a89382 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -523,7 +523,7 @@ [Components]
}
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
- OvmfPkg/PlatformPei/PlatformPei.inf
+ OvmfPkg/XenPlatformPei/XenPlatformPei.inf
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
UefiCpuPkg/CpuMpPei/CpuMpPei.inf
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 6fc8479aae..2ceff7baa2 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -152,7 +152,7 @@ [FV.PEIFV]
INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
-INF OvmfPkg/PlatformPei/PlatformPei.inf
+INF OvmfPkg/XenPlatformPei/XenPlatformPei.inf
INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
new file mode 100644
index 0000000000..d1265c365a
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -0,0 +1,96 @@
+## @file
+# Platform PEI driver
+#
+# This module provides platform specific function to detect boot mode.
+# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION = 0x00010005
+ BASE_NAME = XenPlatformPei
+ FILE_GUID = f112a6ee-993a-4f0b-8295-e52029d9b4ba
+ MODULE_TYPE = PEIM
+ VERSION_STRING = 1.0
+ ENTRY_POINT = InitializeXenPlatform
+
+#
+# The following information is for reference only and not required by the build tools.
+#
+# VALID_ARCHITECTURES = IA32 X64 EBC
+#
+
+[Sources]
+ AmdSev.c
+ ClearCache.c
+ Cmos.c
+ Cmos.h
+ Fv.c
+ MemDetect.c
+ Platform.c
+ Platform.h
+ Xen.c
+ Xen.h
+
+[Packages]
+ MdePkg/MdePkg.dec
+ MdeModulePkg/MdeModulePkg.dec
+ SecurityPkg/SecurityPkg.dec
+ UefiCpuPkg/UefiCpuPkg.dec
+ OvmfPkg/OvmfPkg.dec
+
+[Guids]
+ gEfiMemoryTypeInformationGuid
+ gEfiXenInfoGuid
+
+[LibraryClasses]
+ BaseLib
+ CacheMaintenanceLib
+ DebugLib
+ HobLib
+ IoLib
+ PciLib
+ ResourcePublicationLib
+ PeiServicesLib
+ PeimEntryPoint
+ MtrrLib
+ MemEncryptSevLib
+ PcdLib
+
+[Pcd]
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size
+ gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
+ gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
+ gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
+ gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
+ gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
+ gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
+ gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
+
+[FixedPcd]
+ gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
+
+[Ppis]
+ gEfiPeiMasterBootModePpiGuid
+ gEfiPeiMpServicesPpiGuid
+
+[Depex]
+ TRUE
+
diff --git a/OvmfPkg/XenPlatformPei/Cmos.h b/OvmfPkg/XenPlatformPei/Cmos.h
new file mode 100644
index 0000000000..80ffcb002f
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/Cmos.h
@@ -0,0 +1,52 @@
+/** @file
+ PC/AT CMOS access routines
+
+ Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef __CMOS_H__
+#define __CMOS_H__
+
+/**
+ Reads 8-bits of CMOS data.
+
+ Reads the 8-bits of CMOS data at the location specified by Index.
+ The 8-bit read value is returned.
+
+ @param Index The CMOS location to read.
+
+ @return The value read.
+
+**/
+UINT8
+EFIAPI
+CmosRead8 (
+ IN UINTN Index
+ );
+
+/**
+ Writes 8-bits of CMOS data.
+
+ Writes 8-bits of CMOS data to the location specified by Index
+ with the value specified by Value and returns Value.
+
+ @param Index The CMOS location to write.
+ @param Value The value to write to CMOS.
+
+ @return The value written to CMOS.
+
+**/
+UINT8
+EFIAPI
+CmosWrite8 (
+ IN UINTN Index,
+ IN UINT8 Value
+ );
+
+
+#endif
+
diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
new file mode 100644
index 0000000000..77427496c0
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -0,0 +1,108 @@
+/** @file
+ Platform PEI module include file.
+
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef _PLATFORM_PEI_H_INCLUDED_
+#define _PLATFORM_PEI_H_INCLUDED_
+
+#include <IndustryStandard/E820.h>
+
+VOID
+AddIoMemoryBaseSizeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ UINT64 MemorySize
+ );
+
+VOID
+AddIoMemoryRangeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ EFI_PHYSICAL_ADDRESS MemoryLimit
+ );
+
+VOID
+AddMemoryBaseSizeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ UINT64 MemorySize
+ );
+
+VOID
+AddMemoryRangeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ EFI_PHYSICAL_ADDRESS MemoryLimit
+ );
+
+VOID
+AddReservedMemoryBaseSizeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ UINT64 MemorySize,
+ BOOLEAN Cacheable
+ );
+
+VOID
+AddressWidthInitialization (
+ VOID
+ );
+
+VOID
+Q35TsegMbytesInitialization (
+ VOID
+ );
+
+EFI_STATUS
+PublishPeiMemory (
+ VOID
+ );
+
+UINT32
+GetSystemMemorySizeBelow4gb (
+ VOID
+ );
+
+VOID
+InitializeRamRegions (
+ VOID
+ );
+
+EFI_STATUS
+PeiFvInitialization (
+ VOID
+ );
+
+VOID
+InstallClearCacheCallback (
+ VOID
+ );
+
+EFI_STATUS
+InitializeXen (
+ VOID
+ );
+
+BOOLEAN
+XenDetect (
+ VOID
+ );
+
+VOID
+AmdSevInitialize (
+ VOID
+ );
+
+VOID
+XenPublishRamRegions (
+ VOID
+ );
+
+extern EFI_BOOT_MODE mBootMode;
+
+extern UINT8 mPhysMemAddressWidth;
+
+extern UINT16 mHostBridgeDevId;
+
+#endif // _PLATFORM_PEI_H_INCLUDED_
diff --git a/OvmfPkg/XenPlatformPei/Xen.h b/OvmfPkg/XenPlatformPei/Xen.h
new file mode 100644
index 0000000000..2605481280
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/Xen.h
@@ -0,0 +1,39 @@
+/** @file
+ Ovmf info structure passed by Xen
+
+Copyright (c) 2013, Citrix Systems UK Ltd.<BR>
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef __XEN_H__
+#define __XEN_H__
+
+#include <PiPei.h>
+
+// Physical address of OVMF info
+#define OVMF_INFO_PHYSICAL_ADDRESS 0x00001000
+
+// This structure must match the definition on Xen side
+#pragma pack(1)
+typedef struct {
+ CHAR8 Signature[14]; // XenHVMOVMF\0
+ UINT8 Length; // Length of this structure
+ UINT8 Checksum; // Set such that the sum over bytes 0..length == 0
+ //
+ // Physical address of an array of TablesCount elements.
+ //
+ // Each element contains the physical address of a BIOS table.
+ //
+ EFI_PHYSICAL_ADDRESS Tables;
+ UINT32 TablesCount;
+ //
+ // Physical address of the E820 table, contains E820EntriesCount entries.
+ //
+ EFI_PHYSICAL_ADDRESS E820;
+ UINT32 E820EntriesCount;
+} EFI_XEN_OVMF_INFO;
+#pragma pack()
+
+#endif /* __XEN_H__ */
diff --git a/OvmfPkg/XenPlatformPei/AmdSev.c b/OvmfPkg/XenPlatformPei/AmdSev.c
new file mode 100644
index 0000000000..7ebbb5cc1f
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/AmdSev.c
@@ -0,0 +1,64 @@
+/**@file
+ Initialize Secure Encrypted Virtualization (SEV) support
+
+ Copyright (c) 2017, Advanced Micro Devices. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+//
+// The package level header files this module uses
+//
+#include <Library/DebugLib.h>
+#include <Library/MemEncryptSevLib.h>
+#include <Library/PcdLib.h>
+#include <PiPei.h>
+#include <Register/Amd/Cpuid.h>
+#include <Register/Cpuid.h>
+
+#include "Platform.h"
+
+/**
+
+ Function checks if SEV support is available, if present then it sets
+ the dynamic PcdPteMemoryEncryptionAddressOrMask with memory encryption mask.
+
+ **/
+VOID
+AmdSevInitialize (
+ VOID
+ )
+{
+ CPUID_MEMORY_ENCRYPTION_INFO_EBX Ebx;
+ UINT64 EncryptionMask;
+ RETURN_STATUS PcdStatus;
+
+ //
+ // Check if SEV is enabled
+ //
+ if (!MemEncryptSevIsEnabled ()) {
+ return;
+ }
+
+ //
+ // CPUID Fn8000_001F[EBX] Bit 0:5 (memory encryption bit position)
+ //
+ AsmCpuid (CPUID_MEMORY_ENCRYPTION_INFO, NULL, &Ebx.Uint32, NULL, NULL);
+ EncryptionMask = LShiftU64 (1, Ebx.Bits.PtePosBits);
+
+ //
+ // Set Memory Encryption Mask PCD
+ //
+ PcdStatus = PcdSet64S (PcdPteMemoryEncryptionAddressOrMask, EncryptionMask);
+ ASSERT_RETURN_ERROR (PcdStatus);
+
+ DEBUG ((DEBUG_INFO, "SEV is enabled (mask 0x%lx)\n", EncryptionMask));
+
+ //
+ // Set Pcd to Deny the execution of option ROM when security
+ // violation.
+ //
+ PcdStatus = PcdSet32S (PcdOptionRomImageVerificationPolicy, 0x4);
+ ASSERT_RETURN_ERROR (PcdStatus);
+}
diff --git a/OvmfPkg/XenPlatformPei/ClearCache.c b/OvmfPkg/XenPlatformPei/ClearCache.c
new file mode 100644
index 0000000000..fab53633a9
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/ClearCache.c
@@ -0,0 +1,112 @@
+/**@file
+ Install a callback to clear cache on all processors.
+ This is for conformance with the TCG "Platform Reset Attack Mitigation
+ Specification". Because clearing the CPU caches at boot doesn't impact
+ performance significantly, do it unconditionally, for simplicity's
+ sake.
+
+ Copyright (C) 2018, Red Hat, Inc.
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include <Library/CacheMaintenanceLib.h>
+#include <Library/DebugLib.h>
+#include <Library/PeiServicesLib.h>
+#include <Ppi/MpServices.h>
+
+#include "Platform.h"
+
+/**
+ Invalidate data & instruction caches.
+ All APs execute this function in parallel. The BSP executes the function
+ separately.
+
+ @param[in,out] WorkSpace Pointer to the input/output argument workspace
+ shared by all processors.
+**/
+STATIC
+VOID
+EFIAPI
+ClearCache (
+ IN OUT VOID *WorkSpace
+ )
+{
+ WriteBackInvalidateDataCache ();
+ InvalidateInstructionCache ();
+}
+
+/**
+ Notification function called when EFI_PEI_MP_SERVICES_PPI becomes available.
+
+ @param[in] PeiServices Indirect reference to the PEI Services Table.
+ @param[in] NotifyDescriptor Address of the notification descriptor data
+ structure.
+ @param[in] Ppi Address of the PPI that was installed.
+
+ @return Status of the notification. The status code returned from this
+ function is ignored.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+ClearCacheOnMpServicesAvailable (
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_NOTIFY_DESCRIPTOR *NotifyDescriptor,
+ IN VOID *Ppi
+ )
+{
+ EFI_PEI_MP_SERVICES_PPI *MpServices;
+ EFI_STATUS Status;
+
+ DEBUG ((DEBUG_INFO, "%a: %a\n", gEfiCallerBaseName, __FUNCTION__));
+
+ //
+ // Clear cache on all the APs in parallel.
+ //
+ MpServices = Ppi;
+ Status = MpServices->StartupAllAPs (
+ (CONST EFI_PEI_SERVICES **)PeiServices,
+ MpServices,
+ ClearCache, // Procedure
+ FALSE, // SingleThread
+ 0, // TimeoutInMicroSeconds: inf.
+ NULL // ProcedureArgument
+ );
+ if (EFI_ERROR (Status) && Status != EFI_NOT_STARTED) {
+ DEBUG ((DEBUG_ERROR, "%a: StartupAllAps(): %r\n", __FUNCTION__, Status));
+ return Status;
+ }
+
+ //
+ // Now clear cache on the BSP too.
+ //
+ ClearCache (NULL);
+ return EFI_SUCCESS;
+}
+
+//
+// Notification object for registering the callback, for when
+// EFI_PEI_MP_SERVICES_PPI becomes available.
+//
+STATIC CONST EFI_PEI_NOTIFY_DESCRIPTOR mMpServicesNotify = {
+ EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK | // Flags
+ EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST,
+ &gEfiPeiMpServicesPpiGuid, // Guid
+ ClearCacheOnMpServicesAvailable // Notify
+};
+
+VOID
+InstallClearCacheCallback (
+ VOID
+ )
+{
+ EFI_STATUS Status;
+
+ Status = PeiServicesNotifyPpi (&mMpServicesNotify);
+ if (EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_ERROR, "%a: failed to set up MP Services callback: %r\n",
+ __FUNCTION__, Status));
+ }
+}
diff --git a/OvmfPkg/XenPlatformPei/Cmos.c b/OvmfPkg/XenPlatformPei/Cmos.c
new file mode 100644
index 0000000000..5d9ee67cd8
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/Cmos.c
@@ -0,0 +1,60 @@
+/** @file
+ PC/AT CMOS access routines
+
+ Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+
+#include "Cmos.h"
+#include "Library/IoLib.h"
+
+/**
+ Reads 8-bits of CMOS data.
+
+ Reads the 8-bits of CMOS data at the location specified by Index.
+ The 8-bit read value is returned.
+
+ @param Index The CMOS location to read.
+
+ @return The value read.
+
+**/
+UINT8
+EFIAPI
+CmosRead8 (
+ IN UINTN Index
+ )
+{
+ IoWrite8 (0x70, (UINT8) Index);
+ return IoRead8 (0x71);
+}
+
+
+/**
+ Writes 8-bits of CMOS data.
+
+ Writes 8-bits of CMOS data to the location specified by Index
+ with the value specified by Value and returns Value.
+
+ @param Index The CMOS location to write.
+ @param Value The value to write to CMOS.
+
+ @return The value written to CMOS.
+
+**/
+UINT8
+EFIAPI
+CmosWrite8 (
+ IN UINTN Index,
+ IN UINT8 Value
+ )
+{
+ IoWrite8 (0x70, (UINT8) Index);
+ IoWrite8 (0x71, Value);
+ return Value;
+}
+
diff --git a/OvmfPkg/XenPlatformPei/Fv.c b/OvmfPkg/XenPlatformPei/Fv.c
new file mode 100644
index 0000000000..70e9b52700
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/Fv.c
@@ -0,0 +1,76 @@
+/** @file
+ Build FV related hobs for platform.
+
+ Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "PiPei.h"
+#include "Platform.h"
+#include <Library/DebugLib.h>
+#include <Library/HobLib.h>
+#include <Library/PeiServicesLib.h>
+#include <Library/PcdLib.h>
+
+
+/**
+ Publish PEI & DXE (Decompressed) Memory based FVs to let PEI
+ and DXE know about them.
+
+ @retval EFI_SUCCESS Platform PEI FVs were initialized successfully.
+
+**/
+EFI_STATUS
+PeiFvInitialization (
+ VOID
+ )
+{
+ DEBUG ((DEBUG_INFO, "Platform PEI Firmware Volume Initialization\n"));
+
+ //
+ // Create a memory allocation HOB for the PEI FV.
+ //
+ // Allocate as ACPI NVS is S3 is supported
+ //
+ BuildMemoryAllocationHob (
+ PcdGet32 (PcdOvmfPeiMemFvBase),
+ PcdGet32 (PcdOvmfPeiMemFvSize),
+ EfiBootServicesData
+ );
+
+ //
+ // Let DXE know about the DXE FV
+ //
+ BuildFvHob (PcdGet32 (PcdOvmfDxeMemFvBase), PcdGet32 (PcdOvmfDxeMemFvSize));
+
+ //
+ // Create a memory allocation HOB for the DXE FV.
+ //
+ // If "secure" S3 is needed, then SEC will decompress both PEI and DXE
+ // firmware volumes at S3 resume too, hence we need to keep away the OS from
+ // DXEFV as well. Otherwise we only need to keep away DXE itself from the
+ // DXEFV area.
+ //
+ BuildMemoryAllocationHob (
+ PcdGet32 (PcdOvmfDxeMemFvBase),
+ PcdGet32 (PcdOvmfDxeMemFvSize),
+ EfiBootServicesData
+ );
+
+ //
+ // Let PEI know about the DXE FV so it can find the DXE Core
+ //
+ PeiServicesInstallFvInfoPpi (
+ NULL,
+ (VOID *)(UINTN) PcdGet32 (PcdOvmfDxeMemFvBase),
+ PcdGet32 (PcdOvmfDxeMemFvSize),
+ NULL,
+ NULL
+ );
+
+ return EFI_SUCCESS;
+}
+
diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c b/OvmfPkg/XenPlatformPei/MemDetect.c
new file mode 100644
index 0000000000..cf95f9c474
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/MemDetect.c
@@ -0,0 +1,421 @@
+/**@file
+ Memory Detection for Virtual Machines.
+
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+Module Name:
+
+ MemDetect.c
+
+**/
+
+//
+// The package level header files this module uses
+//
+#include <IndustryStandard/Q35MchIch9.h>
+#include <PiPei.h>
+
+//
+// The Library classes this module consumes
+//
+#include <Library/BaseLib.h>
+#include <Library/BaseMemoryLib.h>
+#include <Library/DebugLib.h>
+#include <Library/HobLib.h>
+#include <Library/IoLib.h>
+#include <Library/PcdLib.h>
+#include <Library/PciLib.h>
+#include <Library/PeimEntryPoint.h>
+#include <Library/ResourcePublicationLib.h>
+
+#include "Platform.h"
+#include "Cmos.h"
+
+UINT8 mPhysMemAddressWidth;
+
+STATIC UINT32 mS3AcpiReservedMemoryBase;
+STATIC UINT32 mS3AcpiReservedMemorySize;
+
+STATIC UINT16 mQ35TsegMbytes;
+
+VOID
+Q35TsegMbytesInitialization (
+ VOID
+ )
+{
+ UINT16 ExtendedTsegMbytes;
+ RETURN_STATUS PcdStatus;
+
+ if (mHostBridgeDevId != INTEL_Q35_MCH_DEVICE_ID) {
+ DEBUG ((
+ DEBUG_ERROR,
+ "%a: no TSEG (SMRAM) on host bridge DID=0x%04x; "
+ "only DID=0x%04x (Q35) is supported\n",
+ __FUNCTION__,
+ mHostBridgeDevId,
+ INTEL_Q35_MCH_DEVICE_ID
+ ));
+ ASSERT (FALSE);
+ CpuDeadLoop ();
+ }
+
+ //
+ // Check if QEMU offers an extended TSEG.
+ //
+ // This can be seen from writing MCH_EXT_TSEG_MB_QUERY to the MCH_EXT_TSEG_MB
+ // register, and reading back the register.
+ //
+ // On a QEMU machine type that does not offer an extended TSEG, the initial
+ // write overwrites whatever value a malicious guest OS may have placed in
+ // the (unimplemented) register, before entering S3 or rebooting.
+ // Subsequently, the read returns MCH_EXT_TSEG_MB_QUERY unchanged.
+ //
+ // On a QEMU machine type that offers an extended TSEG, the initial write
+ // triggers an update to the register. Subsequently, the value read back
+ // (which is guaranteed to differ from MCH_EXT_TSEG_MB_QUERY) tells us the
+ // number of megabytes.
+ //
+ PciWrite16 (DRAMC_REGISTER_Q35 (MCH_EXT_TSEG_MB), MCH_EXT_TSEG_MB_QUERY);
+ ExtendedTsegMbytes = PciRead16 (DRAMC_REGISTER_Q35 (MCH_EXT_TSEG_MB));
+ if (ExtendedTsegMbytes == MCH_EXT_TSEG_MB_QUERY) {
+ mQ35TsegMbytes = PcdGet16 (PcdQ35TsegMbytes);
+ return;
+ }
+
+ DEBUG ((
+ DEBUG_INFO,
+ "%a: QEMU offers an extended TSEG (%d MB)\n",
+ __FUNCTION__,
+ ExtendedTsegMbytes
+ ));
+ PcdStatus = PcdSet16S (PcdQ35TsegMbytes, ExtendedTsegMbytes);
+ ASSERT_RETURN_ERROR (PcdStatus);
+ mQ35TsegMbytes = ExtendedTsegMbytes;
+}
+
+
+UINT32
+GetSystemMemorySizeBelow4gb (
+ VOID
+ )
+{
+ UINT8 Cmos0x34;
+ UINT8 Cmos0x35;
+
+ //
+ // CMOS 0x34/0x35 specifies the system memory above 16 MB.
+ // * CMOS(0x35) is the high byte
+ // * CMOS(0x34) is the low byte
+ // * The size is specified in 64kb chunks
+ // * Since this is memory above 16MB, the 16MB must be added
+ // into the calculation to get the total memory size.
+ //
+
+ Cmos0x34 = (UINT8) CmosRead8 (0x34);
+ Cmos0x35 = (UINT8) CmosRead8 (0x35);
+
+ return (UINT32) (((UINTN)((Cmos0x35 << 8) + Cmos0x34) << 16) + SIZE_16MB);
+}
+
+
+STATIC
+UINT64
+GetSystemMemorySizeAbove4gb (
+ )
+{
+ UINT32 Size;
+ UINTN CmosIndex;
+
+ //
+ // CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
+ // * CMOS(0x5d) is the most significant size byte
+ // * CMOS(0x5c) is the middle size byte
+ // * CMOS(0x5b) is the least significant size byte
+ // * The size is specified in 64kb chunks
+ //
+
+ Size = 0;
+ for (CmosIndex = 0x5d; CmosIndex >= 0x5b; CmosIndex--) {
+ Size = (UINT32) (Size << 8) + (UINT32) CmosRead8 (CmosIndex);
+ }
+
+ return LShiftU64 (Size, 16);
+}
+
+
+/**
+ Return the highest address that DXE could possibly use, plus one.
+**/
+STATIC
+UINT64
+GetFirstNonAddress (
+ VOID
+ )
+{
+ UINT64 FirstNonAddress;
+ UINT64 Pci64Base, Pci64Size;
+ RETURN_STATUS PcdStatus;
+
+ FirstNonAddress = BASE_4GB + GetSystemMemorySizeAbove4gb ();
+
+ //
+ // If DXE is 32-bit, then we're done; PciBusDxe will degrade 64-bit MMIO
+ // resources to 32-bit anyway. See DegradeResource() in
+ // "PciResourceSupport.c".
+ //
+#ifdef MDE_CPU_IA32
+ if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
+ return FirstNonAddress;
+ }
+#endif
+
+ //
+ // Otherwise, in order to calculate the highest address plus one, we must
+ // consider the 64-bit PCI host aperture too. Fetch the default size.
+ //
+ Pci64Size = PcdGet64 (PcdPciMmio64Size);
+
+ if (Pci64Size == 0) {
+ if (mBootMode != BOOT_ON_S3_RESUME) {
+ DEBUG ((DEBUG_INFO, "%a: disabling 64-bit PCI host aperture\n",
+ __FUNCTION__));
+ PcdStatus = PcdSet64S (PcdPciMmio64Size, 0);
+ ASSERT_RETURN_ERROR (PcdStatus);
+ }
+
+ //
+ // There's nothing more to do; the amount of memory above 4GB fully
+ // determines the highest address plus one. The memory hotplug area (see
+ // below) plays no role for the firmware in this case.
+ //
+ return FirstNonAddress;
+ }
+
+ //
+ // SeaBIOS aligns both boundaries of the 64-bit PCI host aperture to 1GB, so
+ // that the host can map it with 1GB hugepages. Follow suit.
+ //
+ Pci64Base = ALIGN_VALUE (FirstNonAddress, (UINT64)SIZE_1GB);
+ Pci64Size = ALIGN_VALUE (Pci64Size, (UINT64)SIZE_1GB);
+
+ //
+ // The 64-bit PCI host aperture should also be "naturally" aligned. The
+ // alignment is determined by rounding the size of the aperture down to the
+ // next smaller or equal power of two. That is, align the aperture by the
+ // largest BAR size that can fit into it.
+ //
+ Pci64Base = ALIGN_VALUE (Pci64Base, GetPowerOfTwo64 (Pci64Size));
+
+ if (mBootMode != BOOT_ON_S3_RESUME) {
+ //
+ // The core PciHostBridgeDxe driver will automatically add this range to
+ // the GCD memory space map through our PciHostBridgeLib instance; here we
+ // only need to set the PCDs.
+ //
+ PcdStatus = PcdSet64S (PcdPciMmio64Base, Pci64Base);
+ ASSERT_RETURN_ERROR (PcdStatus);
+ PcdStatus = PcdSet64S (PcdPciMmio64Size, Pci64Size);
+ ASSERT_RETURN_ERROR (PcdStatus);
+
+ DEBUG ((DEBUG_INFO, "%a: Pci64Base=0x%Lx Pci64Size=0x%Lx\n",
+ __FUNCTION__, Pci64Base, Pci64Size));
+ }
+
+ //
+ // The useful address space ends with the 64-bit PCI host aperture.
+ //
+ FirstNonAddress = Pci64Base + Pci64Size;
+ return FirstNonAddress;
+}
+
+
+/**
+ Initialize the mPhysMemAddressWidth variable, based on guest RAM size.
+**/
+VOID
+AddressWidthInitialization (
+ VOID
+ )
+{
+ UINT64 FirstNonAddress;
+
+ //
+ // As guest-physical memory size grows, the permanent PEI RAM requirements
+ // are dominated by the identity-mapping page tables built by the DXE IPL.
+ // The DXL IPL keys off of the physical address bits advertized in the CPU
+ // HOB. To conserve memory, we calculate the minimum address width here.
+ //
+ FirstNonAddress = GetFirstNonAddress ();
+ mPhysMemAddressWidth = (UINT8)HighBitSet64 (FirstNonAddress);
+
+ //
+ // If FirstNonAddress is not an integral power of two, then we need an
+ // additional bit.
+ //
+ if ((FirstNonAddress & (FirstNonAddress - 1)) != 0) {
+ ++mPhysMemAddressWidth;
+ }
+
+ //
+ // The minimum address width is 36 (covers up to and excluding 64 GB, which
+ // is the maximum for Ia32 + PAE). The theoretical architecture maximum for
+ // X64 long mode is 52 bits, but the DXE IPL clamps that down to 48 bits. We
+ // can simply assert that here, since 48 bits are good enough for 256 TB.
+ //
+ if (mPhysMemAddressWidth <= 36) {
+ mPhysMemAddressWidth = 36;
+ }
+ ASSERT (mPhysMemAddressWidth <= 48);
+}
+
+
+/**
+ Calculate the cap for the permanent PEI memory.
+**/
+STATIC
+UINT32
+GetPeiMemoryCap (
+ VOID
+ )
+{
+ BOOLEAN Page1GSupport;
+ UINT32 RegEax;
+ UINT32 RegEdx;
+ UINT32 Pml4Entries;
+ UINT32 PdpEntries;
+ UINTN TotalPages;
+
+ //
+ // If DXE is 32-bit, then just return the traditional 64 MB cap.
+ //
+#ifdef MDE_CPU_IA32
+ if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
+ return SIZE_64MB;
+ }
+#endif
+
+ //
+ // Dependent on physical address width, PEI memory allocations can be
+ // dominated by the page tables built for 64-bit DXE. So we key the cap off
+ // of those. The code below is based on CreateIdentityMappingPageTables() in
+ // "MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c".
+ //
+ Page1GSupport = FALSE;
+ if (PcdGetBool (PcdUse1GPageTable)) {
+ AsmCpuid (0x80000000, &RegEax, NULL, NULL, NULL);
+ if (RegEax >= 0x80000001) {
+ AsmCpuid (0x80000001, NULL, NULL, NULL, &RegEdx);
+ if ((RegEdx & BIT26) != 0) {
+ Page1GSupport = TRUE;
+ }
+ }
+ }
+
+ if (mPhysMemAddressWidth <= 39) {
+ Pml4Entries = 1;
+ PdpEntries = 1 << (mPhysMemAddressWidth - 30);
+ ASSERT (PdpEntries <= 0x200);
+ } else {
+ Pml4Entries = 1 << (mPhysMemAddressWidth - 39);
+ ASSERT (Pml4Entries <= 0x200);
+ PdpEntries = 512;
+ }
+
+ TotalPages = Page1GSupport ? Pml4Entries + 1 :
+ (PdpEntries + 1) * Pml4Entries + 1;
+ ASSERT (TotalPages <= 0x40201);
+
+ //
+ // Add 64 MB for miscellaneous allocations. Note that for
+ // mPhysMemAddressWidth values close to 36, the cap will actually be
+ // dominated by this increment.
+ //
+ return (UINT32)(EFI_PAGES_TO_SIZE (TotalPages) + SIZE_64MB);
+}
+
+
+/**
+ Publish PEI core memory
+
+ @return EFI_SUCCESS The PEIM initialized successfully.
+
+**/
+EFI_STATUS
+PublishPeiMemory (
+ VOID
+ )
+{
+ EFI_STATUS Status;
+ EFI_PHYSICAL_ADDRESS MemoryBase;
+ UINT64 MemorySize;
+ UINT32 LowerMemorySize;
+ UINT32 PeiMemoryCap;
+
+ LowerMemorySize = GetSystemMemorySizeBelow4gb ();
+
+ if (mBootMode == BOOT_ON_S3_RESUME) {
+ MemoryBase = mS3AcpiReservedMemoryBase;
+ MemorySize = mS3AcpiReservedMemorySize;
+ } else {
+ PeiMemoryCap = GetPeiMemoryCap ();
+ DEBUG ((DEBUG_INFO, "%a: mPhysMemAddressWidth=%d PeiMemoryCap=%u KB\n",
+ __FUNCTION__, mPhysMemAddressWidth, PeiMemoryCap >> 10));
+
+ //
+ // Determine the range of memory to use during PEI
+ //
+ MemoryBase =
+ PcdGet32 (PcdOvmfDxeMemFvBase) + PcdGet32 (PcdOvmfDxeMemFvSize);
+ MemorySize = LowerMemorySize - MemoryBase;
+ if (MemorySize > PeiMemoryCap) {
+ MemoryBase = LowerMemorySize - PeiMemoryCap;
+ MemorySize = PeiMemoryCap;
+ }
+ }
+
+ //
+ // Publish this memory to the PEI Core
+ //
+ Status = PublishSystemMemory(MemoryBase, MemorySize);
+ ASSERT_EFI_ERROR (Status);
+
+ return Status;
+}
+
+
+/**
+ Publish system RAM and reserve memory regions
+
+**/
+VOID
+InitializeRamRegions (
+ VOID
+ )
+{
+ XenPublishRamRegions ();
+
+ if (mBootMode != BOOT_ON_S3_RESUME) {
+ //
+ // Reserve the lock box storage area
+ //
+ // Since this memory range will be used on S3 resume, it must be
+ // reserved as ACPI NVS.
+ //
+ // If S3 is unsupported, then various drivers might still write to the
+ // LockBox area. We ought to prevent DXE from serving allocation requests
+ // such that they would overlap the LockBox storage.
+ //
+ ZeroMem (
+ (VOID*)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
+ (UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize)
+ );
+ BuildMemoryAllocationHob (
+ (EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
+ (UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
+ EfiBootServicesData
+ );
+ }
+}
diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
new file mode 100644
index 0000000000..5809eadb0b
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -0,0 +1,444 @@
+/**@file
+ Platform PEI driver
+
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+//
+// The package level header files this module uses
+//
+#include <PiPei.h>
+
+//
+// The Library classes this module consumes
+//
+#include <Library/BaseLib.h>
+#include <Library/DebugLib.h>
+#include <Library/HobLib.h>
+#include <Library/IoLib.h>
+#include <Library/MemoryAllocationLib.h>
+#include <Library/PcdLib.h>
+#include <Library/PciLib.h>
+#include <Library/PeimEntryPoint.h>
+#include <Library/PeiServicesLib.h>
+#include <Library/ResourcePublicationLib.h>
+#include <Guid/MemoryTypeInformation.h>
+#include <Ppi/MasterBootMode.h>
+#include <IndustryStandard/Pci22.h>
+#include <OvmfPlatforms.h>
+
+#include "Platform.h"
+#include "Cmos.h"
+
+EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = {
+ { EfiACPIMemoryNVS, 0x004 },
+ { EfiACPIReclaimMemory, 0x008 },
+ { EfiReservedMemoryType, 0x004 },
+ { EfiRuntimeServicesData, 0x024 },
+ { EfiRuntimeServicesCode, 0x030 },
+ { EfiBootServicesCode, 0x180 },
+ { EfiBootServicesData, 0xF00 },
+ { EfiMaxMemoryType, 0x000 }
+};
+
+
+EFI_PEI_PPI_DESCRIPTOR mPpiBootMode[] = {
+ {
+ EFI_PEI_PPI_DESCRIPTOR_PPI | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST,
+ &gEfiPeiMasterBootModePpiGuid,
+ NULL
+ }
+};
+
+
+UINT16 mHostBridgeDevId;
+
+EFI_BOOT_MODE mBootMode = BOOT_WITH_FULL_CONFIGURATION;
+
+
+VOID
+AddIoMemoryBaseSizeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ UINT64 MemorySize
+ )
+{
+ BuildResourceDescriptorHob (
+ EFI_RESOURCE_MEMORY_MAPPED_IO,
+ EFI_RESOURCE_ATTRIBUTE_PRESENT |
+ EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
+ EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_TESTED,
+ MemoryBase,
+ MemorySize
+ );
+}
+
+VOID
+AddReservedMemoryBaseSizeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ UINT64 MemorySize,
+ BOOLEAN Cacheable
+ )
+{
+ BuildResourceDescriptorHob (
+ EFI_RESOURCE_MEMORY_RESERVED,
+ EFI_RESOURCE_ATTRIBUTE_PRESENT |
+ EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
+ EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
+ (Cacheable ?
+ EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE :
+ 0
+ ) |
+ EFI_RESOURCE_ATTRIBUTE_TESTED,
+ MemoryBase,
+ MemorySize
+ );
+}
+
+VOID
+AddIoMemoryRangeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ EFI_PHYSICAL_ADDRESS MemoryLimit
+ )
+{
+ AddIoMemoryBaseSizeHob (MemoryBase, (UINT64)(MemoryLimit - MemoryBase));
+}
+
+
+VOID
+AddMemoryBaseSizeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ UINT64 MemorySize
+ )
+{
+ BuildResourceDescriptorHob (
+ EFI_RESOURCE_SYSTEM_MEMORY,
+ EFI_RESOURCE_ATTRIBUTE_PRESENT |
+ EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
+ EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_TESTED,
+ MemoryBase,
+ MemorySize
+ );
+}
+
+
+VOID
+AddMemoryRangeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ EFI_PHYSICAL_ADDRESS MemoryLimit
+ )
+{
+ AddMemoryBaseSizeHob (MemoryBase, (UINT64)(MemoryLimit - MemoryBase));
+}
+
+
+VOID
+MemMapInitialization (
+ VOID
+ )
+{
+ UINT64 PciIoBase;
+ UINT64 PciIoSize;
+ RETURN_STATUS PcdStatus;
+
+ PciIoBase = 0xC000;
+ PciIoSize = 0x4000;
+
+ //
+ // Create Memory Type Information HOB
+ //
+ BuildGuidDataHob (
+ &gEfiMemoryTypeInformationGuid,
+ mDefaultMemoryTypeInformation,
+ sizeof(mDefaultMemoryTypeInformation)
+ );
+
+ //
+ // Video memory + Legacy BIOS region
+ //
+ AddIoMemoryRangeHob (0x0A0000, BASE_1MB);
+
+ //
+ // Add PCI IO Port space available for PCI resource allocations.
+ //
+ BuildResourceDescriptorHob (
+ EFI_RESOURCE_IO,
+ EFI_RESOURCE_ATTRIBUTE_PRESENT |
+ EFI_RESOURCE_ATTRIBUTE_INITIALIZED,
+ PciIoBase,
+ PciIoSize
+ );
+ PcdStatus = PcdSet64S (PcdPciIoBase, PciIoBase);
+ ASSERT_RETURN_ERROR (PcdStatus);
+ PcdStatus = PcdSet64S (PcdPciIoSize, PciIoSize);
+ ASSERT_RETURN_ERROR (PcdStatus);
+}
+
+VOID
+PciExBarInitialization (
+ VOID
+ )
+{
+ union {
+ UINT64 Uint64;
+ UINT32 Uint32[2];
+ } PciExBarBase;
+
+ //
+ // We only support the 256MB size for the MMCONFIG area:
+ // 256 buses * 32 devices * 8 functions * 4096 bytes config space.
+ //
+ // The masks used below enforce the Q35 requirements that the MMCONFIG area
+ // be (a) correctly aligned -- here at 256 MB --, (b) located under 64 GB.
+ //
+ // Note that (b) also ensures that the minimum address width we have
+ // determined in AddressWidthInitialization(), i.e., 36 bits, will suffice
+ // for DXE's page tables to cover the MMCONFIG area.
+ //
+ PciExBarBase.Uint64 = FixedPcdGet64 (PcdPciExpressBaseAddress);
+ ASSERT ((PciExBarBase.Uint32[1] & MCH_PCIEXBAR_HIGHMASK) == 0);
+ ASSERT ((PciExBarBase.Uint32[0] & MCH_PCIEXBAR_LOWMASK) == 0);
+
+ //
+ // Clear the PCIEXBAREN bit first, before programming the high register.
+ //
+ PciWrite32 (DRAMC_REGISTER_Q35 (MCH_PCIEXBAR_LOW), 0);
+
+ //
+ // Program the high register. Then program the low register, setting the
+ // MMCONFIG area size and enabling decoding at once.
+ //
+ PciWrite32 (DRAMC_REGISTER_Q35 (MCH_PCIEXBAR_HIGH), PciExBarBase.Uint32[1]);
+ PciWrite32 (
+ DRAMC_REGISTER_Q35 (MCH_PCIEXBAR_LOW),
+ PciExBarBase.Uint32[0] | MCH_PCIEXBAR_BUS_FF | MCH_PCIEXBAR_EN
+ );
+}
+
+VOID
+MiscInitialization (
+ VOID
+ )
+{
+ UINTN PmCmd;
+ UINTN Pmba;
+ UINT32 PmbaAndVal;
+ UINT32 PmbaOrVal;
+ UINTN AcpiCtlReg;
+ UINT8 AcpiEnBit;
+ RETURN_STATUS PcdStatus;
+
+ //
+ // Disable A20 Mask
+ //
+ IoOr8 (0x92, BIT1);
+
+ //
+ // Build the CPU HOB with guest RAM size dependent address width and 16-bits
+ // of IO space. (Side note: unlike other HOBs, the CPU HOB is needed during
+ // S3 resume as well, so we build it unconditionally.)
+ //
+ BuildCpuHob (mPhysMemAddressWidth, 16);
+
+ //
+ // Determine platform type and save Host Bridge DID to PCD
+ //
+ switch (mHostBridgeDevId) {
+ case INTEL_82441_DEVICE_ID:
+ PmCmd = POWER_MGMT_REGISTER_PIIX4 (PCI_COMMAND_OFFSET);
+ Pmba = POWER_MGMT_REGISTER_PIIX4 (PIIX4_PMBA);
+ PmbaAndVal = ~(UINT32)PIIX4_PMBA_MASK;
+ PmbaOrVal = PIIX4_PMBA_VALUE;
+ AcpiCtlReg = POWER_MGMT_REGISTER_PIIX4 (PIIX4_PMREGMISC);
+ AcpiEnBit = PIIX4_PMREGMISC_PMIOSE;
+ break;
+ case INTEL_Q35_MCH_DEVICE_ID:
+ PmCmd = POWER_MGMT_REGISTER_Q35 (PCI_COMMAND_OFFSET);
+ Pmba = POWER_MGMT_REGISTER_Q35 (ICH9_PMBASE);
+ PmbaAndVal = ~(UINT32)ICH9_PMBASE_MASK;
+ PmbaOrVal = ICH9_PMBASE_VALUE;
+ AcpiCtlReg = POWER_MGMT_REGISTER_Q35 (ICH9_ACPI_CNTL);
+ AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
+ break;
+ default:
+ DEBUG ((DEBUG_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
+ __FUNCTION__, mHostBridgeDevId));
+ ASSERT (FALSE);
+ return;
+ }
+ PcdStatus = PcdSet16S (PcdOvmfHostBridgePciDevId, mHostBridgeDevId);
+ ASSERT_RETURN_ERROR (PcdStatus);
+
+ //
+ // If the appropriate IOspace enable bit is set, assume the ACPI PMBA
+ // has been configured (e.g., by Xen) and skip the setup here.
+ // This matches the logic in AcpiTimerLibConstructor ().
+ //
+ if ((PciRead8 (AcpiCtlReg) & AcpiEnBit) == 0) {
+ //
+ // The PEI phase should be exited with fully accessibe ACPI PM IO space:
+ // 1. set PMBA
+ //
+ PciAndThenOr32 (Pmba, PmbaAndVal, PmbaOrVal);
+
+ //
+ // 2. set PCICMD/IOSE
+ //
+ PciOr8 (PmCmd, EFI_PCI_COMMAND_IO_SPACE);
+
+ //
+ // 3. set ACPI PM IO enable bit (PMREGMISC:PMIOSE or ACPI_CNTL:ACPI_EN)
+ //
+ PciOr8 (AcpiCtlReg, AcpiEnBit);
+ }
+
+ if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
+ //
+ // Set Root Complex Register Block BAR
+ //
+ PciWrite32 (
+ POWER_MGMT_REGISTER_Q35 (ICH9_RCBA),
+ ICH9_ROOT_COMPLEX_BASE | ICH9_RCBA_EN
+ );
+
+ //
+ // Set PCI Express Register Range Base Address
+ //
+ PciExBarInitialization ();
+ }
+}
+
+
+VOID
+BootModeInitialization (
+ VOID
+ )
+{
+ EFI_STATUS Status;
+
+ if (CmosRead8 (0xF) == 0xFE) {
+ mBootMode = BOOT_ON_S3_RESUME;
+ }
+ CmosWrite8 (0xF, 0x00);
+
+ Status = PeiServicesSetBootMode (mBootMode);
+ ASSERT_EFI_ERROR (Status);
+
+ Status = PeiServicesInstallPpi (mPpiBootMode);
+ ASSERT_EFI_ERROR (Status);
+}
+
+
+VOID
+ReserveEmuVariableNvStore (
+ )
+{
+ EFI_PHYSICAL_ADDRESS VariableStore;
+ RETURN_STATUS PcdStatus;
+
+ //
+ // Allocate storage for NV variables early on so it will be
+ // at a consistent address. Since VM memory is preserved
+ // across reboots, this allows the NV variable storage to survive
+ // a VM reboot.
+ //
+ VariableStore =
+ (EFI_PHYSICAL_ADDRESS)(UINTN)
+ AllocateRuntimePages (
+ EFI_SIZE_TO_PAGES (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize))
+ );
+ DEBUG ((DEBUG_INFO,
+ "Reserved variable store memory: 0x%lX; size: %dkb\n",
+ VariableStore,
+ (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)) / 1024
+ ));
+ PcdStatus = PcdSet64S (PcdEmuVariableNvStoreReserved, VariableStore);
+ ASSERT_RETURN_ERROR (PcdStatus);
+}
+
+
+VOID
+DebugDumpCmos (
+ VOID
+ )
+{
+ UINT32 Loop;
+
+ DEBUG ((DEBUG_INFO, "CMOS:\n"));
+
+ for (Loop = 0; Loop < 0x80; Loop++) {
+ if ((Loop % 0x10) == 0) {
+ DEBUG ((DEBUG_INFO, "%02x:", Loop));
+ }
+ DEBUG ((DEBUG_INFO, " %02x", CmosRead8 (Loop)));
+ if ((Loop % 0x10) == 0xf) {
+ DEBUG ((DEBUG_INFO, "\n"));
+ }
+ }
+}
+
+
+
+/**
+ Perform Platform PEI initialization.
+
+ @param FileHandle Handle of the file being invoked.
+ @param PeiServices Describes the list of possible PEI Services.
+
+ @return EFI_SUCCESS The PEIM initialized successfully.
+
+**/
+EFI_STATUS
+EFIAPI
+InitializeXenPlatform (
+ IN EFI_PEI_FILE_HANDLE FileHandle,
+ IN CONST EFI_PEI_SERVICES **PeiServices
+ )
+{
+ DEBUG ((DEBUG_INFO, "Platform PEIM Loaded\n"));
+
+ DebugDumpCmos ();
+
+ if (!XenDetect ()) {
+ DEBUG ((DEBUG_ERROR, "ERROR: Xen isn't detected\n"));
+ ASSERT (FALSE);
+ CpuDeadLoop ();
+ }
+
+ BootModeInitialization ();
+ AddressWidthInitialization ();
+
+ //
+ // Query Host Bridge DID
+ //
+ mHostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
+
+ PublishPeiMemory ();
+
+ InitializeRamRegions ();
+
+ InitializeXen ();
+
+ if (mBootMode != BOOT_ON_S3_RESUME) {
+ ReserveEmuVariableNvStore ();
+ PeiFvInitialization ();
+ MemMapInitialization ();
+ }
+
+ InstallClearCacheCallback ();
+ AmdSevInitialize ();
+ MiscInitialization ();
+
+ return EFI_SUCCESS;
+}
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
new file mode 100644
index 0000000000..f4d0d1c73b
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -0,0 +1,219 @@
+/**@file
+ Xen Platform PEI support
+
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+//
+// The package level header files this module uses
+//
+#include <PiPei.h>
+
+//
+// The Library classes this module consumes
+//
+#include <Library/DebugLib.h>
+#include <Library/HobLib.h>
+#include <Library/MemoryAllocationLib.h>
+#include <Library/PcdLib.h>
+#include <Guid/XenInfo.h>
+#include <IndustryStandard/E820.h>
+#include <Library/ResourcePublicationLib.h>
+#include <Library/MtrrLib.h>
+
+#include "Platform.h"
+#include "Xen.h"
+
+STATIC UINT32 mXenLeaf = 0;
+
+EFI_XEN_INFO mXenInfo;
+
+/**
+ Returns E820 map provided by Xen
+
+ @param Entries Pointer to E820 map
+ @param Count Number of entries
+
+ @return EFI_STATUS
+**/
+EFI_STATUS
+XenGetE820Map (
+ EFI_E820_ENTRY64 **Entries,
+ UINT32 *Count
+ )
+{
+ EFI_XEN_OVMF_INFO *Info =
+ (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+
+ if (AsciiStrCmp ((CHAR8 *) Info->Signature, "XenHVMOVMF")) {
+ return EFI_NOT_FOUND;
+ }
+
+ ASSERT (Info->E820 < MAX_ADDRESS);
+ *Entries = (EFI_E820_ENTRY64 *)(UINTN) Info->E820;
+ *Count = Info->E820EntriesCount;
+
+ return EFI_SUCCESS;
+}
+
+/**
+ Connects to the Hypervisor.
+
+ @param XenLeaf CPUID index used to connect.
+
+ @return EFI_STATUS
+
+**/
+EFI_STATUS
+XenConnect (
+ UINT32 XenLeaf
+ )
+{
+ UINT32 Index;
+ UINT32 TransferReg;
+ UINT32 TransferPages;
+ UINT32 XenVersion;
+
+ AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
+ mXenInfo.HyperPages = AllocatePages (TransferPages);
+ if (!mXenInfo.HyperPages) {
+ return EFI_OUT_OF_RESOURCES;
+ }
+
+ for (Index = 0; Index < TransferPages; Index++) {
+ AsmWriteMsr64 (TransferReg,
+ (UINTN) mXenInfo.HyperPages +
+ (Index << EFI_PAGE_SHIFT) + Index);
+ }
+
+ AsmCpuid (XenLeaf + 1, &XenVersion, NULL, NULL, NULL);
+ DEBUG ((DEBUG_ERROR, "Detected Xen version %d.%d\n",
+ XenVersion >> 16, XenVersion & 0xFFFF));
+ mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
+ mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
+
+ /* TBD: Locate hvm_info and reserve it away. */
+ mXenInfo.HvmInfo = NULL;
+
+ BuildGuidDataHob (
+ &gEfiXenInfoGuid,
+ &mXenInfo,
+ sizeof(mXenInfo)
+ );
+
+ return EFI_SUCCESS;
+}
+
+/**
+ Figures out if we are running inside Xen HVM.
+
+ @retval TRUE Xen was detected
+ @retval FALSE Xen was not detected
+
+**/
+BOOLEAN
+XenDetect (
+ VOID
+ )
+{
+ UINT8 Signature[13];
+
+ if (mXenLeaf != 0) {
+ return TRUE;
+ }
+
+ Signature[12] = '\0';
+ for (mXenLeaf = 0x40000000; mXenLeaf < 0x40010000; mXenLeaf += 0x100) {
+ AsmCpuid (mXenLeaf,
+ NULL,
+ (UINT32 *) &Signature[0],
+ (UINT32 *) &Signature[4],
+ (UINT32 *) &Signature[8]);
+
+ if (!AsciiStrCmp ((CHAR8 *) Signature, "XenVMMXenVMM")) {
+ return TRUE;
+ }
+ }
+
+ mXenLeaf = 0;
+ return FALSE;
+}
+
+
+VOID
+XenPublishRamRegions (
+ VOID
+ )
+{
+ EFI_E820_ENTRY64 *E820Map;
+ UINT32 E820EntriesCount;
+ EFI_STATUS Status;
+
+ DEBUG ((DEBUG_INFO, "Using memory map provided by Xen\n"));
+
+ //
+ // Parse RAM in E820 map
+ //
+ E820EntriesCount = 0;
+ Status = XenGetE820Map (&E820Map, &E820EntriesCount);
+
+ ASSERT_EFI_ERROR (Status);
+
+ if (E820EntriesCount > 0) {
+ EFI_E820_ENTRY64 *Entry;
+ UINT32 Loop;
+
+ for (Loop = 0; Loop < E820EntriesCount; Loop++) {
+ Entry = E820Map + Loop;
+
+ //
+ // Only care about RAM
+ //
+ if (Entry->Type != EfiAcpiAddressRangeMemory) {
+ continue;
+ }
+
+ AddMemoryBaseSizeHob (Entry->BaseAddr, Entry->Length);
+
+ MtrrSetMemoryAttribute (Entry->BaseAddr, Entry->Length, CacheWriteBack);
+ }
+ }
+}
+
+
+/**
+ Perform Xen PEI initialization.
+
+ @return EFI_SUCCESS Xen initialized successfully
+ @return EFI_NOT_FOUND Not running under Xen
+
+**/
+EFI_STATUS
+InitializeXen (
+ VOID
+ )
+{
+ RETURN_STATUS PcdStatus;
+
+ if (mXenLeaf == 0) {
+ return EFI_NOT_FOUND;
+ }
+
+ XenConnect (mXenLeaf);
+
+ //
+ // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
+ // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
+ //
+ AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
+
+ PcdStatus = PcdSetBoolS (PcdPciDisableBusEnumeration, TRUE);
+ ASSERT_RETURN_ERROR (PcdStatus);
+
+ return EFI_SUCCESS;
+}
diff --git a/Maintainers.txt b/Maintainers.txt
index 34bdb275b4..42ec8d54af 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -379,6 +379,7 @@ F: OvmfPkg/PlatformPei/Xen.*
F: OvmfPkg/SmbiosPlatformDxe/*Xen.c
F: OvmfPkg/XenBusDxe/
F: OvmfPkg/XenIoPciDxe/
+F: OvmfPkg/XenPlatformPei/
F: OvmfPkg/XenPvBlkDxe/
F: OvmfPkg/XenResetVector/
R: Anthony Perard <anthony.perard@citrix.com>
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 04/35] OvmfPkg: Introduce XenPlatformPei
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 04/35] OvmfPkg: Introduce XenPlatformPei Anthony PERARD
@ 2019-07-30 9:21 ` Laszlo Ersek
0 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 9:21 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Jordan Justen
On 07/29/19 17:39, Anthony PERARD wrote:
> Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some
> of QEMU specific initialization, Xen does not support QemuFwCfg.
>
> This new module will be adjusted to accommodate Xen PVH.
>
> fw_cfg dependents that have been removed, which are dynamically skipped
> when running PlatformPei on Xen:
> - GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
> (experimental) "opt/ovmf/X-PciMmio64Mb" file
> - GetFirstNonAddress(): honoring the hotplug DIMM area
> ("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO
> aperture
> - NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
> PcdSetNxForStack are left constant FALSE (not set dynamically from
> fw_cfg "opt/ovmf/PcdXxxx")
> - MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
> not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
> PcdCpuMaxLogicalProcessorNumber is used intact and
> PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
> - InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
> consulting "etc/system-states" via QemuFwCfgS3Enabled()).
> - InstallFeatureControlCallback(): the feature control MSR is not set
> from "etc/msr_feature_control"
> (also removed FeatureControl.c as there is nothing been executed)
>
> Also removed:
> - SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
> assumed FALSE) in PublishPeiMemory(),
> - QemuInitializeRam() entirely,
>
> Xen related changes:
> - Have removed the module variable mXen, as it should be always true.
> - Have the platform PEI initialization fails if Xen has not been
> detected.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - replace the other EFI_D_ by DEBUG_.
> - Update Maintainers.txt
> - fix one trailing whitespace
>
> v3:
> - fix coding style in new code
> (use DEBUG_xxx, add ASSERT before CpuDeadLoop)
> - rebased, SPDX
>
> OvmfPkg/OvmfXen.dsc | 2 +-
> OvmfPkg/OvmfXen.fdf | 2 +-
> OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 96 +++++
> OvmfPkg/XenPlatformPei/Cmos.h | 52 +++
> OvmfPkg/XenPlatformPei/Platform.h | 108 ++++++
> OvmfPkg/XenPlatformPei/Xen.h | 39 ++
> OvmfPkg/XenPlatformPei/AmdSev.c | 64 ++++
> OvmfPkg/XenPlatformPei/ClearCache.c | 112 ++++++
> OvmfPkg/XenPlatformPei/Cmos.c | 60 +++
> OvmfPkg/XenPlatformPei/Fv.c | 76 ++++
> OvmfPkg/XenPlatformPei/MemDetect.c | 421 ++++++++++++++++++++
> OvmfPkg/XenPlatformPei/Platform.c | 444 ++++++++++++++++++++++
> OvmfPkg/XenPlatformPei/Xen.c | 219 +++++++++++
> Maintainers.txt | 1 +
> 14 files changed, 1694 insertions(+), 2 deletions(-)
> create mode 100644 OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> create mode 100644 OvmfPkg/XenPlatformPei/Cmos.h
> create mode 100644 OvmfPkg/XenPlatformPei/Platform.h
> create mode 100644 OvmfPkg/XenPlatformPei/Xen.h
> create mode 100644 OvmfPkg/XenPlatformPei/AmdSev.c
> create mode 100644 OvmfPkg/XenPlatformPei/ClearCache.c
> create mode 100644 OvmfPkg/XenPlatformPei/Cmos.c
> create mode 100644 OvmfPkg/XenPlatformPei/Fv.c
> create mode 100644 OvmfPkg/XenPlatformPei/MemDetect.c
> create mode 100644 OvmfPkg/XenPlatformPei/Platform.c
> create mode 100644 OvmfPkg/XenPlatformPei/Xen.c
[...]
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 34bdb275b4..42ec8d54af 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -379,6 +379,7 @@ F: OvmfPkg/PlatformPei/Xen.*
> F: OvmfPkg/SmbiosPlatformDxe/*Xen.c
> F: OvmfPkg/XenBusDxe/
> F: OvmfPkg/XenIoPciDxe/
> +F: OvmfPkg/XenPlatformPei/
> F: OvmfPkg/XenPvBlkDxe/
> F: OvmfPkg/XenResetVector/
> R: Anthony Perard <anthony.perard@citrix.com>
>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 05/35] OvmfPkg/OvmfXen: Creating an ELF header
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (3 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 04/35] OvmfPkg: Introduce XenPlatformPei Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 9:25 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 06/35] OvmfPkg/XenResetVector: Add new entry point for Xen PVH Anthony PERARD
` (31 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This patch changes the flash device image of OvmfXen to make it look
like it's an ELF. For this, we replace the empty embedded variable store
by a binary array, which is a ELF file header.
The ELF header explain to a loader to load the binary at the address
1MB, then jump to the PVH entry point which will be created in a later
patch. The header also includes a Xen ELF note that is part of the
PVH ABI.
That patch include OvmfXenElfHeaderGenerator.c which can be use to
regenerate the ELF header, but this will be a manual step.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- fix top-level comment style
- Update Maintainers.txt
v3:
- added license to generate_elf_header.c
which is renamed to OvmfPkg/OvmfXenElfHeaderGenerator.c
- added an ELF NOTE into the header
OvmfPkg/OvmfXen.fdf | 101 +++++++++++++++++++-
| 140 ++++++++++++++++++++++++++++
Maintainers.txt | 1 +
3 files changed, 239 insertions(+), 3 deletions(-)
create mode 100644 OvmfPkg/OvmfXenElfHeaderGenerator.c
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 2ceff7baa2..43c268f6cb 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -15,8 +15,8 @@ [Defines]
!include OvmfPkg.fdf.inc
#
-# Build the variable store and the firmware code as one unified flash device
-# image.
+# This will allow the flash device image to be recognize as an ELF, with first
+# an ELF headers, then the firmware code.
#
[FD.OVMF]
BaseAddress = $(FW_BASE_ADDRESS)
@@ -25,7 +25,102 @@ [FD.OVMF]
BlockSize = $(BLOCK_SIZE)
NumBlocks = $(FW_BLOCKS)
-!include VarStore.fdf.inc
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x00000000|0x0000e000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00000000|0x00040000
+!endif
+DATA = {
+ #
+ # This hex array have been generated by OvmfPkg/OvmfXenElfHeaderGenerator.c
+ # and copied manually.
+ #
+ # ELF file header
+ 0x7f, 0x45, 0x4c, 0x46, # e_ident[0..3]: Magic number
+ 0x01, # File class: 32-bit objects
+ 0x01, # Data encoding: 2's complement, little endian
+ 0x01, # File version
+ 0x03, # OS ABI identification: Object uses GNU ELF extensions
+ 0x00, # ABI version
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, # e_ident[EI_PAD...]
+ 0x02, 0x00, # e_type = Executable file
+ 0x03, 0x00, # e_machine = Intel 80386
+ 0x01, 0x00, 0x00, 0x00, # e_version
+ 0xd0, 0xff, 0x2f, 0x00, # e_entry: Entry point virtual address
+ 0x34, 0x00, 0x00, 0x00, # e_phoff: Program header table file offset
+ 0x00, 0x00, 0x00, 0x00, # e_shoff: Section header table file offset
+ 0x00, 0x00, 0x00, 0x00, # e_flags: Processor-specific flags
+ 0x34, 0x00, # e_ehsize: ELF header size
+ 0x20, 0x00, # e_phentsize: Program header table entry size
+ 0x02, 0x00, # e_phnum: Program header table entry count
+ 0x00, 0x00, # e_shentsize: Section header table entry size
+ 0x00, 0x00, # e_shnum: Section header table entry count
+ 0x00, 0x00, # e_shstrndx
+
+ # ELF Program segment headers
+ # - Load segment
+ 0x01, 0x00, 0x00, 0x00, # p_type = Loadable program segment
+ 0x00, 0x00, 0x00, 0x00, # p_offset
+ 0x00, 0x00, 0x10, 0x00, # p_vaddr: Segment virtual address
+ 0x00, 0x00, 0x10, 0x00, # p_paddr: Segment physical address
+ 0x00, 0x00, 0x20, 0x00, # p_filesz: Segment size in file
+ 0x00, 0x00, 0x20, 0x00, # p_memsz: Segment size in memory
+ 0x07, 0x00, 0x00, 0x00, # p_flags = Segment is executable | writable | readable
+ 0x00, 0x00, 0x00, 0x00, # p_align
+ # - ELFNOTE segment
+ 0x04, 0x00, 0x00, 0x00, # p_type = PT_NOTE
+ 0x74, 0x00, 0x00, 0x00, # p_offset = point to XEN_ELFNOTE_PHYS32_ENTRY below
+ 0x74, 0x00, 0x10, 0x00,
+ 0x74, 0x00, 0x10, 0x00,
+ 0x14, 0x00, 0x00, 0x00,
+ 0x14, 0x00, 0x00, 0x00,
+ 0x04, 0x00, 0x00, 0x00, # p_flags = Segment is readable
+ 0x00, 0x00, 0x00, 0x00,
+
+ # XEN_ELFNOTE_PHYS32_ENTRY
+ 0x04, 0x00, 0x00, 0x00, # name size
+ 0x04, 0x00, 0x00, 0x00, # desc size
+ 0x12, 0x00, 0x00, 0x00, # type = XEN_ELFNOTE_PHYS32_ENTRY
+ 0x58, 0x65, 0x6e, 0x00, # name = "Xen"
+ 0xd0, 0xff, 0x2f, 0x00, # desc: PVH entry point
+ 0x00
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0000e000|0x00001000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00040000|0x00001000
+!endif
+#NV_EVENT_LOG
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0000f000|0x00001000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00041000|0x00001000
+!endif
+#NV_FTW_WORKING
+DATA = {
+ # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = gEdkiiWorkingBlockSignatureGuid =
+ # { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95 }}
+ 0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
+ 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95,
+ # Crc:UINT32 #WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
+ 0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
+ # WriteQueueSize: UINT64
+ 0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x00010000|0x00010000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00042000|0x00042000
+!endif
+#NV_FTW_SPARE
+
$(VARS_SIZE)|$(FVMAIN_SIZE)
FV = FVMAIN_COMPACT
--git a/OvmfPkg/OvmfXenElfHeaderGenerator.c b/OvmfPkg/OvmfXenElfHeaderGenerator.c
new file mode 100644
index 0000000000..90f0574fc6
--- /dev/null
+++ b/OvmfPkg/OvmfXenElfHeaderGenerator.c
@@ -0,0 +1,140 @@
+/** @file
+ This program generates a hex array to be manually coppied into
+ OvmfXen.fdf.
+
+ The purpose is for the flash device image to be recognize as an ELF.
+
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "elf.h"
+#include "stdio.h"
+#include "stddef.h"
+
+void print_hdr(void *s, size_t size)
+{
+ char *c = s;
+
+ while (size--) {
+ printf("0x%02hhx, ", *(c++));
+ }
+}
+
+/* Format for the XEN_ELFNOTE_PHYS32_ENTRY program segment */
+#define XEN_ELFNOTE_PHYS32_ENTRY 18
+typedef struct {
+ uint32_t name_size;
+ uint32_t desc_size;
+ uint32_t type;
+ char name[4];
+ uint32_t desc;
+} xen_elfnote_phys32_entry;
+
+int main(void)
+{
+ /* FW_SIZE */
+ size_t ovmf_blob_size = 0x00200000;
+ /* Load OVMF at 1MB when running as PVH guest */
+ uint32_t ovmf_base_address = 0x00100000;
+ /* Xen PVH entry point */
+ uint32_t ovmfxen_pvh_entry_point = ovmf_base_address + ovmf_blob_size - 0x30;
+ size_t offset_into_file = 0;
+
+ /* ELF file header */
+ Elf32_Ehdr hdr = {
+ .e_ident = ELFMAG,
+ .e_type = ET_EXEC,
+ .e_machine = EM_386,
+ .e_version = EV_CURRENT,
+ .e_entry = ovmfxen_pvh_entry_point,
+ .e_flags = R_386_NONE,
+ .e_ehsize = sizeof (hdr),
+ .e_phentsize = sizeof (Elf32_Phdr),
+ };
+ offset_into_file += sizeof (hdr);
+
+ hdr.e_ident[EI_CLASS] = ELFCLASS32;
+ hdr.e_ident[EI_DATA] = ELFDATA2LSB;
+ hdr.e_ident[EI_VERSION] = EV_CURRENT;
+ hdr.e_ident[EI_OSABI] = ELFOSABI_LINUX;
+ /* Placing program headers just after hdr */
+ hdr.e_phoff = sizeof (hdr);
+
+ /* program header */
+ Elf32_Phdr phdr_load = {
+ .p_type = PT_LOAD,
+ .p_offset = 0, /* load everything */
+ .p_paddr = ovmf_base_address,
+ .p_filesz = ovmf_blob_size,
+ .p_memsz = ovmf_blob_size,
+ .p_flags = PF_X | PF_W | PF_R,
+ .p_align = 0,
+ };
+ phdr_load.p_vaddr = phdr_load.p_paddr;
+ hdr.e_phnum += 1;
+ offset_into_file += sizeof (phdr_load);
+
+ /* Xen ELF Note. */
+
+ xen_elfnote_phys32_entry xen_elf_note = {
+ .type = XEN_ELFNOTE_PHYS32_ENTRY,
+ .name = "Xen",
+ .desc = ovmfxen_pvh_entry_point,
+ .name_size =
+ offsetof (xen_elfnote_phys32_entry, desc) -
+ offsetof (xen_elfnote_phys32_entry, name),
+ .desc_size =
+ sizeof (xen_elfnote_phys32_entry) -
+ offsetof (xen_elfnote_phys32_entry, desc),
+ };
+ Elf32_Phdr phdr_note = {
+ .p_type = PT_NOTE,
+ .p_filesz = sizeof (xen_elf_note),
+ .p_memsz = sizeof (xen_elf_note),
+ .p_flags = PF_R,
+ .p_align = 0,
+ };
+ hdr.e_phnum += 1;
+ offset_into_file += sizeof (phdr_note);
+ phdr_note.p_offset = offset_into_file;
+ phdr_note.p_paddr = ovmf_base_address + phdr_note.p_offset;
+ phdr_note.p_vaddr = phdr_note.p_paddr;
+
+
+ /*
+ * print elf header
+ */
+
+ size_t i;
+ size_t hdr_size = sizeof (hdr);
+ size_t entry_off = offsetof(typeof(hdr), e_entry);
+
+ printf("# ELF file header\n");
+ print_hdr(&hdr, entry_off);
+ printf("\n");
+ print_hdr(&hdr.e_entry, sizeof (hdr.e_entry));
+ printf(" # hdr.e_entry\n");
+ print_hdr(&hdr.e_entry + 1, hdr_size - entry_off - sizeof (hdr.e_entry));
+
+ printf("\n\n# ELF Program segment headers\n");
+ printf("# - Load segment\n");
+ for (i = 0; i < sizeof (phdr_load); i += 4) {
+ print_hdr(((char*)&phdr_load) + i, 4);
+ printf("\n");
+ }
+ printf("# - ELFNOTE segment\n");
+ for (i = 0; i < sizeof (phdr_note); i += 4) {
+ print_hdr(((char*)&phdr_note) + i, 4);
+ printf("\n");
+ }
+
+ printf("\n# XEN_ELFNOTE_PHYS32_ENTRY\n");
+ for (i = 0; i < sizeof (xen_elf_note); i += 4) {
+ print_hdr(((char*)&xen_elf_note) + i, 4);
+ printf("\n");
+ }
+
+ return 0;
+}
diff --git a/Maintainers.txt b/Maintainers.txt
index 42ec8d54af..016523b401 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -373,6 +373,7 @@ F: OvmfPkg/Library/XenConsoleSerialPortLib/
F: OvmfPkg/Library/XenHypercallLib/
F: OvmfPkg/Library/XenIoMmioLib/
F: OvmfPkg/OvmfXen.*
+F: OvmfPkg/OvmfXenElfHeaderGenerator.c
F: OvmfPkg/PlatformPei/MemDetect.c
F: OvmfPkg/PlatformPei/Platform.*
F: OvmfPkg/PlatformPei/Xen.*
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 05/35] OvmfPkg/OvmfXen: Creating an ELF header
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 05/35] OvmfPkg/OvmfXen: Creating an ELF header Anthony PERARD
@ 2019-07-30 9:25 ` Laszlo Ersek
0 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 9:25 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Jordan Justen
On 07/29/19 17:39, Anthony PERARD wrote:
> This patch changes the flash device image of OvmfXen to make it look
> like it's an ELF. For this, we replace the empty embedded variable store
> by a binary array, which is a ELF file header.
>
> The ELF header explain to a loader to load the binary at the address
> 1MB, then jump to the PVH entry point which will be created in a later
> patch. The header also includes a Xen ELF note that is part of the
> PVH ABI.
>
> That patch include OvmfXenElfHeaderGenerator.c which can be use to
> regenerate the ELF header, but this will be a manual step.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - fix top-level comment style
> - Update Maintainers.txt
>
> v3:
> - added license to generate_elf_header.c
> which is renamed to OvmfPkg/OvmfXenElfHeaderGenerator.c
> - added an ELF NOTE into the header
>
> OvmfPkg/OvmfXen.fdf | 101 +++++++++++++++++++-
> OvmfPkg/OvmfXenElfHeaderGenerator.c | 140 ++++++++++++++++++++++++++++
> Maintainers.txt | 1 +
> 3 files changed, 239 insertions(+), 3 deletions(-)
> create mode 100644 OvmfPkg/OvmfXenElfHeaderGenerator.c
[...]
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 42ec8d54af..016523b401 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -373,6 +373,7 @@ F: OvmfPkg/Library/XenConsoleSerialPortLib/
> F: OvmfPkg/Library/XenHypercallLib/
> F: OvmfPkg/Library/XenIoMmioLib/
> F: OvmfPkg/OvmfXen.*
> +F: OvmfPkg/OvmfXenElfHeaderGenerator.c
> F: OvmfPkg/PlatformPei/MemDetect.c
> F: OvmfPkg/PlatformPei/Platform.*
> F: OvmfPkg/PlatformPei/Xen.*
>
Acked-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 06/35] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (4 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 05/35] OvmfPkg/OvmfXen: Creating an ELF header Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 9:33 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-08-07 11:37 ` [Xen-devel] " Roger Pau Monné
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 07/35] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests Anthony PERARD
` (30 subsequent siblings)
36 siblings, 2 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Andrew Cooper,
Anthony PERARD, xen-devel, Laszlo Ersek, Roger Pau Monné
Add a new entry point for Xen PVH that enter directly in 32bits.
Information on the expected state of the machine when this entry point
is used can be found at:
https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
Also, compare to the original file [1], the two `nop' of the "resetVector"
entry point are removed. There were introduced by 8332983e2e33
("UefiCpuPkg: Replace the un-necessary WBINVD instruction at the reset
vector with two NOPs in VTF0.", 2011-08-04), but don't seems to be
useful. This is the entry point used by HVM guest (hvmloader).
[1] UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- remove the two nop in the HVM entry point
v3:
- rebased, SPDX
- remove `cli' as via PVH the interrupts are guaranteed to be off
- rewrite some comments
.../XenResetVector/Ia16/ResetVectorVtf0.asm | 79 +++++++++++++++++++
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 49 ++++++++++++
OvmfPkg/XenResetVector/XenResetVector.nasmb | 1 +
3 files changed, 129 insertions(+)
create mode 100644 OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
create mode 100644 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
diff --git a/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
new file mode 100644
index 0000000000..56749bdbc9
--- /dev/null
+++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
@@ -0,0 +1,79 @@
+;------------------------------------------------------------------------------
+; @file
+; First code executed by processor after resetting.
+;
+; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+BITS 16
+
+ALIGN 16
+
+;
+; Pad the image size to 4k when page tables are in VTF0
+;
+; If the VTF0 image has page tables built in, then we need to make
+; sure the end of VTF0 is 4k above where the page tables end.
+;
+; This is required so the page tables will be 4k aligned when VTF0 is
+; located just below 0x100000000 (4GB) in the firmware device.
+;
+%ifdef ALIGN_TOP_TO_4K_FOR_PAGING
+ TIMES (0x1000 - ($ - EndOfPageTables) - (fourGigabytes - xenPVHEntryPoint)) DB 0
+%endif
+
+BITS 32
+xenPVHEntryPoint:
+;
+; Entry point to use when running as a Xen PVH guest. (0xffffffd0)
+;
+; Description of the expected state of the machine when this entry point is
+; used can be found at:
+; https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
+;
+ jmp xenPVHMain
+
+BITS 16
+ALIGN 16
+
+applicationProcessorEntryPoint:
+;
+; Application Processors entry point
+;
+; GenFv generates code aligned on a 4k boundary which will jump to this
+; location. (0xffffffe0) This allows the Local APIC Startup IPI to be
+; used to wake up the application processors.
+;
+ jmp EarlyApInitReal16
+
+ALIGN 8
+
+ DD 0
+
+;
+; The VTF signature
+;
+; VTF-0 means that the VTF (Volume Top File) code does not require
+; any fixups.
+;
+vtfSignature:
+ DB 'V', 'T', 'F', 0
+
+ALIGN 16
+
+resetVector:
+;
+; Reset Vector
+;
+; This is where the processor will begin execution
+;
+ jmp EarlyBspInitReal16
+
+ALIGN 16
+
+fourGigabytes:
+
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
new file mode 100644
index 0000000000..2a17fed52f
--- /dev/null
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -0,0 +1,49 @@
+;------------------------------------------------------------------------------
+; @file
+; An entry point use by Xen when a guest is started in PVH mode.
+;
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+BITS 32
+
+xenPVHMain:
+ ;
+ ; 'BP' to indicate boot-strap processor
+ ;
+ mov di, 'BP'
+
+ ;
+ ; ESP will be used as initial value of the EAX register
+ ; in Main.asm
+ ;
+ xor esp, esp
+
+ mov ebx, ADDR_OF(gdtr)
+ lgdt [ebx]
+
+ mov eax, SEC_DEFAULT_CR0
+ mov cr0, eax
+
+ jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
+.jmpToNewCodeSeg:
+
+ mov eax, SEC_DEFAULT_CR4
+ mov cr4, eax
+
+ mov ax, LINEAR_SEL
+ mov ds, ax
+ mov es, ax
+ mov fs, ax
+ mov gs, ax
+ mov ss, ax
+
+ ;
+ ; Jump to the main routine of the pre-SEC code
+ ; skiping the 16-bit part of the routine and
+ ; into the 32-bit flat mode part
+ ;
+ OneTimeCallRet TransitionFromReal16To32BitFlat
diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
index 89a4b08bc3..0dbc4f2c1d 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -63,6 +63,7 @@
%include "Ia16/Init16.asm"
%include "Main.asm"
+%include "Ia32/XenPVHMain.asm"
%include "Ia16/ResetVectorVtf0.asm"
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 06/35] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 06/35] OvmfPkg/XenResetVector: Add new entry point for Xen PVH Anthony PERARD
@ 2019-07-30 9:33 ` Laszlo Ersek
2019-08-07 11:37 ` [Xen-devel] " Roger Pau Monné
1 sibling, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 9:33 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Ard Biesheuvel, Andrew Cooper, Julien Grall, Jordan Justen,
xen-devel, Roger Pau Monné
On 07/29/19 17:39, Anthony PERARD wrote:
> Add a new entry point for Xen PVH that enter directly in 32bits.
>
> Information on the expected state of the machine when this entry point
> is used can be found at:
> https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
>
> Also, compare to the original file [1], the two `nop' of the "resetVector"
> entry point are removed. There were introduced by 8332983e2e33
> ("UefiCpuPkg: Replace the un-necessary WBINVD instruction at the reset
> vector with two NOPs in VTF0.", 2011-08-04), but don't seems to be
> useful. This is the entry point used by HVM guest (hvmloader).
>
> [1] UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - remove the two nop in the HVM entry point
Also, new paragraph in the commit message.
Acked-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [Xen-devel] [PATCH v4 06/35] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 06/35] OvmfPkg/XenResetVector: Add new entry point for Xen PVH Anthony PERARD
2019-07-30 9:33 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
@ 2019-08-07 11:37 ` Roger Pau Monné
1 sibling, 0 replies; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 11:37 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall,
Andrew Cooper, xen-devel, Laszlo Ersek
On Mon, Jul 29, 2019 at 04:39:15PM +0100, Anthony PERARD wrote:
> Add a new entry point for Xen PVH that enter directly in 32bits.
>
> Information on the expected state of the machine when this entry point
> is used can be found at:
> https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
>
> Also, compare to the original file [1], the two `nop' of the "resetVector"
> entry point are removed. There were introduced by 8332983e2e33
> ("UefiCpuPkg: Replace the un-necessary WBINVD instruction at the reset
> vector with two NOPs in VTF0.", 2011-08-04), but don't seems to be
> useful. This is the entry point used by HVM guest (hvmloader).
>
> [1] UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - remove the two nop in the HVM entry point
>
> v3:
> - rebased, SPDX
> - remove `cli' as via PVH the interrupts are guaranteed to be off
> - rewrite some comments
>
> .../XenResetVector/Ia16/ResetVectorVtf0.asm | 79 +++++++++++++++++++
> OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 49 ++++++++++++
> OvmfPkg/XenResetVector/XenResetVector.nasmb | 1 +
> 3 files changed, 129 insertions(+)
> create mode 100644 OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> create mode 100644 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>
> diff --git a/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> new file mode 100644
> index 0000000000..56749bdbc9
> --- /dev/null
> +++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> @@ -0,0 +1,79 @@
> +;------------------------------------------------------------------------------
> +; @file
> +; First code executed by processor after resetting.
> +;
> +; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.<BR>
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> +; SPDX-License-Identifier: BSD-2-Clause-Patent
> +;
> +;------------------------------------------------------------------------------
> +
> +BITS 16
> +
> +ALIGN 16
> +
> +;
> +; Pad the image size to 4k when page tables are in VTF0
> +;
> +; If the VTF0 image has page tables built in, then we need to make
> +; sure the end of VTF0 is 4k above where the page tables end.
> +;
> +; This is required so the page tables will be 4k aligned when VTF0 is
> +; located just below 0x100000000 (4GB) in the firmware device.
> +;
> +%ifdef ALIGN_TOP_TO_4K_FOR_PAGING
> + TIMES (0x1000 - ($ - EndOfPageTables) - (fourGigabytes - xenPVHEntryPoint)) DB 0
> +%endif
> +
> +BITS 32
I think you likely want an ALIGN 32 here in case
ALIGN_TOP_TO_4K_FOR_PAGING is not defined, so that xenPVHEntryPoint is
aligned to a double word boundary?
(not that it's mandatory for this to work)
The rest LGTM.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 07/35] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (5 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 06/35] OvmfPkg/XenResetVector: Add new entry point for Xen PVH Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 08/35] OvmfPkg/XenResetVector: Allow jumpstart from either hvmloader or PVH Anthony PERARD
` (29 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Andrew Cooper,
Anthony PERARD, xen-devel, Laszlo Ersek, Roger Pau Monné
As described in the Xen PVH documentation [1], "ebx: contains the
physical memory address where the loader has placed the boot start info
structure". To have this pointer saved to be able to use it later in the
PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as
a signature (for "Xen PVH").
[1] https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- rename PcdXenStartOfDay* to PcdXenPvhStartOfDay*
- Use first available token value for those (0x17 and 0x28)
OvmfPkg/OvmfPkg.dec | 3 +++
OvmfPkg/OvmfXen.fdf | 4 ++++
OvmfPkg/XenResetVector/XenResetVector.inf | 3 +++
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 6 ++++++
OvmfPkg/XenResetVector/XenResetVector.nasmb | 2 ++
5 files changed, 18 insertions(+)
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 9640360f62..c2a2ebfb95 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -218,6 +218,9 @@ [PcdsFixedAtBuild]
# The value should be a multiple of 4KB.
gUefiOvmfPkgTokenSpaceGuid.PcdHighPmmMemorySize|0x400000|UINT32|0x31
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|0x0|UINT32|0x17
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize|0x0|UINT32|0x32
+
[PcdsDynamic, PcdsDynamicEx]
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 43c268f6cb..49997fee9b 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -172,6 +172,10 @@ [FD.MEMFD]
0x007000|0x001000
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
+0x008000|0x001000
+# Used by XenResetVector to communicate with XenPlatformPei
+gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
+
0x010000|0x010000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
diff --git a/OvmfPkg/XenResetVector/XenResetVector.inf b/OvmfPkg/XenResetVector/XenResetVector.inf
index 097fc9b5b4..46b133a834 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.inf
+++ b/OvmfPkg/XenResetVector/XenResetVector.inf
@@ -36,3 +36,6 @@ [BuildOptions]
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
+
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
index 2a17fed52f..f42df3dba2 100644
--- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -22,6 +22,12 @@ xenPVHMain:
;
xor esp, esp
+ ;
+ ; Store "Start of day" struct pointer for later use
+ ;
+ mov dword[PVH_SPACE (0)], ebx
+ mov dword[PVH_SPACE (4)], 'XPVH'
+
mov ebx, ADDR_OF(gdtr)
lgdt [ebx]
diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb
index 0dbc4f2c1d..b2cb405d54 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -34,6 +34,8 @@
%include "CommonMacros.inc"
+%define PVH_SPACE(Offset) (FixedPcdGet32 (PcdXenPvhStartOfDayStructPtr) + (Offset))
+
%include "PostCodes.inc"
%ifdef DEBUG_PORT80
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 08/35] OvmfPkg/XenResetVector: Allow jumpstart from either hvmloader or PVH
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (6 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 07/35] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 09/35] OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU Anthony PERARD
` (28 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Andrew Cooper,
Anthony PERARD, xen-devel, Laszlo Ersek, Roger Pau Monné
This patch allows the ResetVector to be run indenpendently from build
time addresses.
The goal of the patch is to avoid having to create RAM just below 4G
when creating a Xen PVH guest while being compatible with the way
hvmloader currently load OVMF, just below 4G.
Only the new PVH entry point will do the calculation.
The ResetVector will figure out its current running address by creating
a temporary stack, make a call and calculate the difference between the
build time address and the address at run time.
This patch copies and make the necessary modification to some other asm
files:
- copy of UefiCpuPkg/.../Flat32ToFlat64.asm:
Allow Transition32FlatTo64Flat to be run from anywhere in memory
- copy of UefiCpuPkg/../SearchForBfvBase.asm:
Add a extra parameter to indicate where to start the search for the
boot firmware volume.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- rebased, SPDX
- fix commit message
.../XenResetVector/Ia16/Real16ToFlat32.asm | 3 +
.../XenResetVector/Ia32/Flat32ToFlat64.asm | 68 +++++++++++++++
.../XenResetVector/Ia32/SearchForBfvBase.asm | 87 +++++++++++++++++++
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 43 +++++++--
4 files changed, 194 insertions(+), 7 deletions(-)
create mode 100644 OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
create mode 100644 OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
diff --git a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
index 5c329bfaea..36ea74f7fe 100644
--- a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
+++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
@@ -54,6 +54,9 @@ jumpTo32BitAndLandHere:
mov gs, ax
mov ss, ax
+ ; parameter for Flat32SearchForBfvBase
+ xor eax, eax ; Start searching from top of 4GB for BfvBase
+
OneTimeCallRet TransitionFromReal16To32BitFlat
ALIGN 2
diff --git a/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
new file mode 100644
index 0000000000..661a8e7028
--- /dev/null
+++ b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
@@ -0,0 +1,68 @@
+;------------------------------------------------------------------------------
+; @file
+; Transition from 32 bit flat protected mode into 64 bit flat protected mode
+;
+; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+BITS 32
+
+;
+; Modified: EAX, EBX, ECX, EDX, ESP
+;
+Transition32FlatTo64Flat:
+
+ OneTimeCall SetCr3ForPageTables64
+
+ mov eax, cr4
+ bts eax, 5 ; enable PAE
+ mov cr4, eax
+
+ mov ecx, 0xc0000080
+ rdmsr
+ bts eax, 8 ; set LME
+ wrmsr
+
+ mov eax, cr0
+ bts eax, 31 ; set PG
+ mov cr0, eax ; enable paging
+
+ ;
+ ; backup ESP
+ ;
+ mov ebx, esp
+
+ ;
+ ; recalculate delta
+ ;
+ mov esp, PVH_SPACE(16)
+ call .delta
+.delta:
+ pop edx
+ sub edx, ADDR_OF(.delta)
+
+ ;
+ ; push return addr and seg to the stack, then return far
+ ;
+ push dword LINEAR_CODE64_SEL
+ mov eax, ADDR_OF(jumpTo64BitAndLandHere)
+ add eax, edx ; add delta
+ push eax
+ retf
+
+BITS 64
+jumpTo64BitAndLandHere:
+
+ ;
+ ; restore ESP
+ ;
+ mov esp, ebx
+
+ debugShowPostCode POSTCODE_64BIT_MODE
+
+ OneTimeCallRet Transition32FlatTo64Flat
+
diff --git a/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
new file mode 100644
index 0000000000..190389c46f
--- /dev/null
+++ b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
@@ -0,0 +1,87 @@
+;------------------------------------------------------------------------------
+; @file
+; Search for the Boot Firmware Volume (BFV) base address
+;
+; Copyright (c) 2008 - 2009, Intel Corporation. All rights reserved.<BR>
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+;#define EFI_FIRMWARE_FILE_SYSTEM2_GUID \
+; { 0x8c8ce578, 0x8a3d, 0x4f1c, { 0x99, 0x35, 0x89, 0x61, 0x85, 0xc3, 0x2d, 0xd3 } }
+%define FFS_GUID_DWORD0 0x8c8ce578
+%define FFS_GUID_DWORD1 0x4f1c8a3d
+%define FFS_GUID_DWORD2 0x61893599
+%define FFS_GUID_DWORD3 0xd32dc385
+
+BITS 32
+
+;
+; Modified: EAX, EBX, ECX
+; Preserved: EDI, ESP
+;
+; @param[in] EAX Start search from here
+; @param[out] EBP Address of Boot Firmware Volume (BFV)
+;
+Flat32SearchForBfvBase:
+
+ mov ecx, eax
+searchingForBfvHeaderLoop:
+ ;
+ ; We check for a firmware volume at every 4KB address in the 16MB
+ ; just below where we started, ECX.
+ ;
+ sub eax, 0x1000
+ mov ebx, ecx
+ sub ebx, eax
+ cmp ebx, 0x01000000
+ ; if ECX-EAX > 16MB; jump notfound
+ ja searchedForBfvHeaderButNotFound
+
+ ;
+ ; Check FFS GUID
+ ;
+ cmp dword [eax + 0x10], FFS_GUID_DWORD0
+ jne searchingForBfvHeaderLoop
+ cmp dword [eax + 0x14], FFS_GUID_DWORD1
+ jne searchingForBfvHeaderLoop
+ cmp dword [eax + 0x18], FFS_GUID_DWORD2
+ jne searchingForBfvHeaderLoop
+ cmp dword [eax + 0x1c], FFS_GUID_DWORD3
+ jne searchingForBfvHeaderLoop
+
+ ;
+ ; Check FV Length
+ ;
+ cmp dword [eax + 0x24], 0
+ jne searchingForBfvHeaderLoop
+ mov ebx, eax
+ add ebx, dword [eax + 0x20]
+ cmp ebx, ecx
+ jnz searchingForBfvHeaderLoop
+
+ jmp searchedForBfvHeaderAndItWasFound
+
+searchedForBfvHeaderButNotFound:
+ ;
+ ; Hang if the SEC entry point was not found
+ ;
+ debugShowPostCode POSTCODE_BFV_NOT_FOUND
+
+ ;
+ ; 0xbfbfbfbf in the EAX & EBP registers helps signal what failed
+ ; for debugging purposes.
+ ;
+ mov eax, 0xBFBFBFBF
+ mov ebp, eax
+ jmp $
+
+searchedForBfvHeaderAndItWasFound:
+ mov ebp, eax
+
+ debugShowPostCode POSTCODE_BFV_FOUND
+
+ OneTimeCallRet Flat32SearchForBfvBase
+
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
index f42df3dba2..2df0f12e18 100644
--- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -16,25 +16,42 @@ xenPVHMain:
;
mov di, 'BP'
- ;
- ; ESP will be used as initial value of the EAX register
- ; in Main.asm
- ;
- xor esp, esp
-
;
; Store "Start of day" struct pointer for later use
;
mov dword[PVH_SPACE (0)], ebx
mov dword[PVH_SPACE (4)], 'XPVH'
+ ;
+ ; calculate delta between build-addr and run position
+ ;
+ mov esp, PVH_SPACE(16) ; create a temporary stack
+ call .delta
+.delta:
+ pop edx ; get addr of .delta
+ sub edx, ADDR_OF(.delta) ; calculate delta
+
+ ;
+ ; Find address of GDT and gdtr and fix the later
+ ;
mov ebx, ADDR_OF(gdtr)
+ add ebx, edx ; add delta gdtr
+ mov eax, ADDR_OF(GDT_BASE)
+ add eax, edx ; add delta to GDT_BASE
+ mov dword[ebx + 2], eax ; fix GDT_BASE addr in gdtr
lgdt [ebx]
mov eax, SEC_DEFAULT_CR0
mov cr0, eax
- jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
+ ;
+ ; push return addr to the stack, then return far
+ ;
+ push dword LINEAR_CODE_SEL ; segment to select
+ mov eax, ADDR_OF(.jmpToNewCodeSeg) ; return addr
+ add eax, edx ; add delta to return addr
+ push eax
+ retf
.jmpToNewCodeSeg:
mov eax, SEC_DEFAULT_CR4
@@ -47,6 +64,18 @@ xenPVHMain:
mov gs, ax
mov ss, ax
+ ;
+ ; ESP will be used as initial value of the EAX register
+ ; in Main.asm
+ ;
+ xor esp, esp
+
+ ;
+ ; parameter for Flat32SearchForBfvBase
+ ;
+ mov eax, ADDR_OF(fourGigabytes)
+ add eax, edx ; add delta
+
;
; Jump to the main routine of the pre-SEC code
; skiping the 16-bit part of the routine and
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 09/35] OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (7 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 08/35] OvmfPkg/XenResetVector: Allow jumpstart from either hvmloader or PVH Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 9:41 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-08-07 14:25 ` [Xen-devel] " Roger Pau Monné
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 10/35] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader Anthony PERARD
` (27 subsequent siblings)
36 siblings, 2 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Andrew Cooper,
Anthony PERARD, xen-devel, Laszlo Ersek, Roger Pau Monné
The ACPI Timer isn't present in a PVH guest, but local APIC works on
both PVH and HVM.
Note that the use of SecPeiDxeTimerLibCpu might be an issue with a
driver of type DXE_RUNTIME_DRIVER. I've attempted to find out which of
the DXE_RUNTIME_DRIVER uses the TimerLib at runtime. I've done that by
replacing the TimerLib evaluation in
[LibraryClasses.common.DXE_RUNTIME_DRIVER] by a different one and
checking every module that uses it (with the --report-file=report
build option).
ResetSystemRuntimeDxe is calling the TimerLib API at runtime to do the
operation "EfiResetCold", so this may never complete if the OS have
disabled the Local APIC Timer.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- reworded the first sentence, use "not present" instead of "don't work".
v3:
- cleanup .dsc, leave only one TimerLib resolution
- Added a note in the commit message regarding the use of the local apic
by runtime drivers
OvmfPkg/OvmfXen.dsc | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 7619a89382..b40d39e003 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -104,7 +104,7 @@ [SkuIds]
################################################################################
[LibraryClasses]
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
@@ -202,7 +202,6 @@ [LibraryClasses.common]
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
[LibraryClasses.common.SEC]
- TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
@@ -281,7 +280,6 @@ [LibraryClasses.common.DXE_CORE]
[LibraryClasses.common.DXE_RUNTIME_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
@@ -298,7 +296,6 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
[LibraryClasses.common.UEFI_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
@@ -313,7 +310,6 @@ [LibraryClasses.common.UEFI_DRIVER]
[LibraryClasses.common.DXE_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
@@ -337,7 +333,6 @@ [LibraryClasses.common.DXE_DRIVER]
[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 09/35] OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 09/35] OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU Anthony PERARD
@ 2019-07-30 9:41 ` Laszlo Ersek
2019-08-07 14:25 ` [Xen-devel] " Roger Pau Monné
1 sibling, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 9:41 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Ard Biesheuvel, Andrew Cooper, Julien Grall, Jordan Justen,
xen-devel, Roger Pau Monné
On 07/29/19 17:39, Anthony PERARD wrote:
> The ACPI Timer isn't present in a PVH guest, but local APIC works on
> both PVH and HVM.
>
> Note that the use of SecPeiDxeTimerLibCpu might be an issue with a
> driver of type DXE_RUNTIME_DRIVER. I've attempted to find out which of
> the DXE_RUNTIME_DRIVER uses the TimerLib at runtime. I've done that by
> replacing the TimerLib evaluation in
> [LibraryClasses.common.DXE_RUNTIME_DRIVER] by a different one and
> checking every module that uses it (with the --report-file=report
> build option).
>
> ResetSystemRuntimeDxe is calling the TimerLib API at runtime to do the
> operation "EfiResetCold", so this may never complete if the OS have
> disabled the Local APIC Timer.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - reworded the first sentence, use "not present" instead of "don't work".
Plus two typo fixes.
Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [PATCH v4 09/35] OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 09/35] OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU Anthony PERARD
2019-07-30 9:41 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
@ 2019-08-07 14:25 ` Roger Pau Monné
1 sibling, 0 replies; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 14:25 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall,
Andrew Cooper, xen-devel, Laszlo Ersek
On Mon, Jul 29, 2019 at 04:39:18PM +0100, Anthony PERARD wrote:
> The ACPI Timer isn't present in a PVH guest, but local APIC works on
> both PVH and HVM.
>
> Note that the use of SecPeiDxeTimerLibCpu might be an issue with a
> driver of type DXE_RUNTIME_DRIVER. I've attempted to find out which of
> the DXE_RUNTIME_DRIVER uses the TimerLib at runtime. I've done that by
> replacing the TimerLib evaluation in
> [LibraryClasses.common.DXE_RUNTIME_DRIVER] by a different one and
> checking every module that uses it (with the --report-file=report
> build option).
>
> ResetSystemRuntimeDxe is calling the TimerLib API at runtime to do the
> operation "EfiResetCold", so this may never complete if the OS have
> disabled the Local APIC Timer.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - reworded the first sentence, use "not present" instead of "don't work".
Thanks, I'm afraid I cannot comment on the change itself, but the
comment message is accurate now :).
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 10/35] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (8 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 09/35] OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 11/35] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820 Anthony PERARD
` (26 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
EFI_XEN_OVMF_INFO is only useful to retrieve the E820 table. The
mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
retrieve the E820 table.
Also remove the unused pointer from the XenInfo HOB as that information
is only useful in the XenPlatformPei.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- fix coding style
- fix commit message
OvmfPkg/Include/Guid/XenInfo.h | 4 ----
OvmfPkg/PlatformPei/Xen.c | 3 ---
OvmfPkg/XenPlatformPei/Xen.c | 25 +++++++++++++++++++++++--
3 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
index 25d76a7828..b052d618fd 100644
--- a/OvmfPkg/Include/Guid/XenInfo.h
+++ b/OvmfPkg/Include/Guid/XenInfo.h
@@ -18,10 +18,6 @@ typedef struct {
///
VOID *HyperPages;
///
- /// Location of the hvm_info page.
- ///
- VOID *HvmInfo;
- ///
/// Hypervisor major version.
///
UINT16 VersionMajor;
diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
index 89dc4143b2..3e15b32a73 100644
--- a/OvmfPkg/PlatformPei/Xen.c
+++ b/OvmfPkg/PlatformPei/Xen.c
@@ -98,9 +98,6 @@ XenConnect (
mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
- /* TBD: Locate hvm_info and reserve it away. */
- mXenInfo.HvmInfo = NULL;
-
BuildGuidDataHob (
&gEfiXenInfoGuid,
&mXenInfo,
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index f4d0d1c73b..9962fe9fc7 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -33,6 +33,12 @@ STATIC UINT32 mXenLeaf = 0;
EFI_XEN_INFO mXenInfo;
+//
+// Location of the firmware info struct setup by hvmloader.
+// Only the E820 table is used by OVMF.
+//
+EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
+
/**
Returns E820 map provided by Xen
@@ -78,6 +84,8 @@ XenConnect (
UINT32 TransferReg;
UINT32 TransferPages;
UINT32 XenVersion;
+ EFI_XEN_OVMF_INFO *Info;
+ CHAR8 Sig[sizeof (Info->Signature) + 1];
AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -97,8 +105,21 @@ XenConnect (
mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
mXenInfo.VersionMinor = (UINT16)(XenVersion & 0xFFFF);
- /* TBD: Locate hvm_info and reserve it away. */
- mXenInfo.HvmInfo = NULL;
+ //
+ // Check if there are information left by hvmloader
+ //
+
+ Info = (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+ //
+ // Copy the signature, and make it null-terminated.
+ //
+ AsciiStrnCpyS (Sig, sizeof (Sig), (CHAR8 *) &Info->Signature,
+ sizeof (Info->Signature));
+ if (AsciiStrCmp (Sig, "XenHVMOVMF") == 0) {
+ mXenHvmloaderInfo = Info;
+ } else {
+ mXenHvmloaderInfo = NULL;
+ }
BuildGuidDataHob (
&gEfiXenInfoGuid,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 11/35] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (9 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 10/35] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 12/35] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct Anthony PERARD
` (25 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Use the already checked pointer mXenHvmloaderInfo to retrieve the E820
table produced by hvmloader.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/XenPlatformPei/Xen.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 9962fe9fc7..5c7d7ddc1c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -53,18 +53,18 @@ XenGetE820Map (
UINT32 *Count
)
{
- EFI_XEN_OVMF_INFO *Info =
- (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+ //
+ // Get E820 produced by hvmloader
+ //
+ if (mXenHvmloaderInfo != NULL) {
+ ASSERT (mXenHvmloaderInfo->E820 < MAX_ADDRESS);
+ *Entries = (EFI_E820_ENTRY64 *)(UINTN) mXenHvmloaderInfo->E820;
+ *Count = mXenHvmloaderInfo->E820EntriesCount;
- if (AsciiStrCmp ((CHAR8 *) Info->Signature, "XenHVMOVMF")) {
- return EFI_NOT_FOUND;
+ return EFI_SUCCESS;
}
- ASSERT (Info->E820 < MAX_ADDRESS);
- *Entries = (EFI_E820_ENTRY64 *)(UINTN) Info->E820;
- *Count = Info->E820EntriesCount;
-
- return EFI_SUCCESS;
+ return EFI_NOT_FOUND;
}
/**
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 12/35] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (10 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 11/35] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820 Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-08-07 14:35 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 13/35] OvmfPkg/Library/XenPlatformLib: New library Anthony PERARD
` (24 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Check if there's a start of the day struct provided to PVH guest, save
the ACPI RSDP address for later.
This patch import import arch-x86/hvm/start_info.h from xen.git.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- use SPDX
- use SIGNATURE_32
- fix coding style
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 3 +
OvmfPkg/Include/Guid/XenInfo.h | 4 +
.../Xen/arch-x86/hvm/start_info.h | 143 ++++++++++++++++++
OvmfPkg/XenPlatformPei/Xen.c | 25 +++
4 files changed, 175 insertions(+)
create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index d1265c365a..4d00206d09 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -84,6 +84,9 @@ [Pcd]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
+
[FixedPcd]
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
index b052d618fd..25743b3884 100644
--- a/OvmfPkg/Include/Guid/XenInfo.h
+++ b/OvmfPkg/Include/Guid/XenInfo.h
@@ -25,6 +25,10 @@ typedef struct {
/// Hypervisor minor version.
///
UINT16 VersionMinor;
+ ///
+ /// Pointer to the RSDP found in the hvm_start_info provided to a PVH guest
+ ///
+ VOID *RsdpPvh;
} EFI_XEN_INFO;
extern EFI_GUID gEfiXenInfoGuid;
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
new file mode 100644
index 0000000000..15708d6dd5
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
@@ -0,0 +1,143 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright (c) 2016, Citrix Systems, Inc.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+
+/*
+ * Start of day structure passed to PVH guests and to HVM guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ * 0 +----------------+
+ * | magic | Contains the magic value XEN_HVM_START_MAGIC_VALUE
+ * | | ("xEn3" with the 0x80 bit of the "E" set).
+ * 4 +----------------+
+ * | version | Version of this structure. Current version is 1. New
+ * | | versions are guaranteed to be backwards-compatible.
+ * 8 +----------------+
+ * | flags | SIF_xxx flags.
+ * 12 +----------------+
+ * | nr_modules | Number of modules passed to the kernel.
+ * 16 +----------------+
+ * | modlist_paddr | Physical address of an array of modules
+ * | | (layout of the structure below).
+ * 24 +----------------+
+ * | cmdline_paddr | Physical address of the command line,
+ * | | a zero-terminated ASCII string.
+ * 32 +----------------+
+ * | rsdp_paddr | Physical address of the RSDP ACPI data structure.
+ * 40 +----------------+
+ * | memmap_paddr | Physical address of the (optional) memory map. Only
+ * | | present in version 1 and newer of the structure.
+ * 48 +----------------+
+ * | memmap_entries | Number of entries in the memory map table. Zero
+ * | | if there is no memory map being provided. Only
+ * | | present in version 1 and newer of the structure.
+ * 52 +----------------+
+ * | reserved | Version 1 and newer only.
+ * 56 +----------------+
+ *
+ * The layout of each entry in the module structure is the following:
+ *
+ * 0 +----------------+
+ * | paddr | Physical address of the module.
+ * 8 +----------------+
+ * | size | Size of the module in bytes.
+ * 16 +----------------+
+ * | cmdline_paddr | Physical address of the command line,
+ * | | a zero-terminated ASCII string.
+ * 24 +----------------+
+ * | reserved |
+ * 32 +----------------+
+ *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ * 0 +----------------+
+ * | addr | Base address
+ * 8 +----------------+
+ * | size | Size of mapping in bytes
+ * 16 +----------------+
+ * | type | Type of mapping as defined between the hypervisor
+ * | | and guest. See XEN_HVM_MEMMAP_TYPE_* values below.
+ * 20 +----------------|
+ * | reserved |
+ * 24 +----------------+
+ *
+ * The address and sizes are always a 64bit little endian unsigned integer.
+ *
+ * NB: Xen on x86 will always try to place all the data below the 4GiB
+ * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0: Initial implementation.
+ *
+ * Version 1: Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ * padding) to the end of the hvm_start_info struct. These new
+ * fields can be used to pass a memory map to the guest. The
+ * memory map is optional and so guests that understand version 1
+ * of the structure must check that memmap_entries is non-zero
+ * before trying to read the memory map.
+ */
+#define XEN_HVM_START_MAGIC_VALUE 0x336ec578
+
+/*
+ * The values used in the type field of the memory map table entries are
+ * defined below and match the Address Range Types as defined in the "System
+ * Address Map Interfaces" section of the ACPI Specification. Please refer to
+ * section 15 in version 6.2 of the ACPI spec: http://uefi.org/specifications
+ */
+#define XEN_HVM_MEMMAP_TYPE_RAM 1
+#define XEN_HVM_MEMMAP_TYPE_RESERVED 2
+#define XEN_HVM_MEMMAP_TYPE_ACPI 3
+#define XEN_HVM_MEMMAP_TYPE_NVS 4
+#define XEN_HVM_MEMMAP_TYPE_UNUSABLE 5
+#define XEN_HVM_MEMMAP_TYPE_DISABLED 6
+#define XEN_HVM_MEMMAP_TYPE_PMEM 7
+
+/*
+ * C representation of the x86/HVM start info layout.
+ *
+ * The canonical definition of this layout is above, this is just a way to
+ * represent the layout described there using C types.
+ */
+struct hvm_start_info {
+ UINT32 magic; /* Contains the magic value 0x336ec578 */
+ /* ("xEn3" with the 0x80 bit of the "E" set).*/
+ UINT32 version; /* Version of this structure. */
+ UINT32 flags; /* SIF_xxx flags. */
+ UINT32 nr_modules; /* Number of modules passed to the kernel. */
+ UINT64 modlist_paddr; /* Physical address of an array of */
+ /* hvm_modlist_entry. */
+ UINT64 cmdline_paddr; /* Physical address of the command line. */
+ UINT64 rsdp_paddr; /* Physical address of the RSDP ACPI data */
+ /* structure. */
+ /* All following fields only present in version 1 and newer */
+ UINT64 memmap_paddr; /* Physical address of an array of */
+ /* hvm_memmap_table_entry. */
+ UINT32 memmap_entries; /* Number of entries in the memmap table. */
+ /* Value will be zero if there is no memory */
+ /* map being provided. */
+ UINT32 reserved; /* Must be zero. */
+};
+
+struct hvm_modlist_entry {
+ UINT64 paddr; /* Physical address of the module. */
+ UINT64 size; /* Size of the module in bytes. */
+ UINT64 cmdline_paddr; /* Physical address of the command line. */
+ UINT64 reserved;
+};
+
+struct hvm_memmap_table_entry {
+ UINT64 addr; /* Base address of the memory region */
+ UINT64 size; /* Size of the memory region in bytes */
+ UINT32 type; /* Mapping type */
+ UINT32 reserved; /* Must be zero for Version 1. */
+};
+
+#endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 5c7d7ddc1c..b366139a0a 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -25,6 +25,7 @@
#include <IndustryStandard/E820.h>
#include <Library/ResourcePublicationLib.h>
#include <Library/MtrrLib.h>
+#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
#include "Platform.h"
#include "Xen.h"
@@ -86,6 +87,7 @@ XenConnect (
UINT32 XenVersion;
EFI_XEN_OVMF_INFO *Info;
CHAR8 Sig[sizeof (Info->Signature) + 1];
+ UINT32 *PVHResetVectorData;
AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -121,6 +123,29 @@ XenConnect (
mXenHvmloaderInfo = NULL;
}
+ mXenInfo.RsdpPvh = NULL;
+
+ //
+ // Locate and use information from the start of day structure if we have
+ // booted via the PVH entry point.
+ //
+
+ PVHResetVectorData = (VOID *)(UINTN) PcdGet32 (PcdXenPvhStartOfDayStructPtr);
+ //
+ // That magic value is written in XenResetVector/Ia32/XenPVHMain.asm
+ //
+ if (PVHResetVectorData[1] == SIGNATURE_32 ('X', 'P', 'V', 'H')) {
+ struct hvm_start_info *HVMStartInfo;
+
+ HVMStartInfo = (VOID *)(UINTN) PVHResetVectorData[0];
+ if (HVMStartInfo->magic == XEN_HVM_START_MAGIC_VALUE) {
+ ASSERT (HVMStartInfo->rsdp_paddr != 0);
+ if (HVMStartInfo->rsdp_paddr != 0) {
+ mXenInfo.RsdpPvh = (VOID *)(UINTN)HVMStartInfo->rsdp_paddr;
+ }
+ }
+ }
+
BuildGuidDataHob (
&gEfiXenInfoGuid,
&mXenInfo,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 12/35] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 12/35] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct Anthony PERARD
@ 2019-08-07 14:35 ` Roger Pau Monné
2019-08-08 10:26 ` Anthony PERARD
0 siblings, 1 reply; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 14:35 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Laszlo Ersek, Jordan Justen
On Mon, Jul 29, 2019 at 04:39:21PM +0100, Anthony PERARD wrote:
> Check if there's a start of the day struct provided to PVH guest, save
> the ACPI RSDP address for later.
>
> This patch import import arch-x86/hvm/start_info.h from xen.git.
You seem to change the types when importing start_info.h, is that
absolutely necessary?
From my experience working with different projects when importing such
headers it's better to keep them verbatim, this makes importing future
versions from upstream easier.
I have a comment below, but it's more like a question.
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 5c7d7ddc1c..b366139a0a 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -25,6 +25,7 @@
> #include <IndustryStandard/E820.h>
> #include <Library/ResourcePublicationLib.h>
> #include <Library/MtrrLib.h>
> +#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
>
> #include "Platform.h"
> #include "Xen.h"
> @@ -86,6 +87,7 @@ XenConnect (
> UINT32 XenVersion;
> EFI_XEN_OVMF_INFO *Info;
> CHAR8 Sig[sizeof (Info->Signature) + 1];
> + UINT32 *PVHResetVectorData;
>
> AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> mXenInfo.HyperPages = AllocatePages (TransferPages);
> @@ -121,6 +123,29 @@ XenConnect (
> mXenHvmloaderInfo = NULL;
> }
>
> + mXenInfo.RsdpPvh = NULL;
> +
> + //
> + // Locate and use information from the start of day structure if we have
> + // booted via the PVH entry point.
> + //
> +
> + PVHResetVectorData = (VOID *)(UINTN) PcdGet32 (PcdXenPvhStartOfDayStructPtr);
> + //
> + // That magic value is written in XenResetVector/Ia32/XenPVHMain.asm
> + //
> + if (PVHResetVectorData[1] == SIGNATURE_32 ('X', 'P', 'V', 'H')) {
> + struct hvm_start_info *HVMStartInfo;
> +
> + HVMStartInfo = (VOID *)(UINTN) PVHResetVectorData[0];
> + if (HVMStartInfo->magic == XEN_HVM_START_MAGIC_VALUE) {
> + ASSERT (HVMStartInfo->rsdp_paddr != 0);
> + if (HVMStartInfo->rsdp_paddr != 0) {
> + mXenInfo.RsdpPvh = (VOID *)(UINTN)HVMStartInfo->rsdp_paddr;
I guess you can do this because OVMF has an identity map of virtual
addresses to physical addresses?
I wonder the size of such identity map, and whether you need to check
that the rsdp address is indeed inside of that region before
converting it to a pointer. The same would apply to
PcdXenPvhStartOfDayStructPtr, but that's likely safe because it's
always < 4GB, which I assume OVMF always has identity mapped?
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 12/35] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
2019-08-07 14:35 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
@ 2019-08-08 10:26 ` Anthony PERARD
2019-08-08 10:40 ` Roger Pau Monné
0 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-08-08 10:26 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Wed, Aug 07, 2019 at 04:35:58PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:21PM +0100, Anthony PERARD wrote:
> > Check if there's a start of the day struct provided to PVH guest, save
> > the ACPI RSDP address for later.
> >
> > This patch import import arch-x86/hvm/start_info.h from xen.git.
>
> You seem to change the types when importing start_info.h, is that
> absolutely necessary?
I guess one could try to map xen's types to EDKII's type with typedefs,
but I'm not sur how well that would work. Importing the xen headers is
documented so changing the types is fairly easy, see
https://github.com/tianocore/edk2/blob/master/OvmfPkg/Include/IndustryStandard/Xen/README
Also, changing the header further might have been something useful to
do, we could have match EDKII's naming convention and source files would
have looked a bit less weird.
> From my experience working with different projects when importing such
> headers it's better to keep them verbatim, this makes importing future
> versions from upstream easier.
>
> I have a comment below, but it's more like a question.
>
> > diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> > index 5c7d7ddc1c..b366139a0a 100644
> > --- a/OvmfPkg/XenPlatformPei/Xen.c
> > +++ b/OvmfPkg/XenPlatformPei/Xen.c
> > @@ -25,6 +25,7 @@
> > #include <IndustryStandard/E820.h>
> > #include <Library/ResourcePublicationLib.h>
> > #include <Library/MtrrLib.h>
> > +#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
> >
> > #include "Platform.h"
> > #include "Xen.h"
> > @@ -86,6 +87,7 @@ XenConnect (
> > UINT32 XenVersion;
> > EFI_XEN_OVMF_INFO *Info;
> > CHAR8 Sig[sizeof (Info->Signature) + 1];
> > + UINT32 *PVHResetVectorData;
> >
> > AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> > mXenInfo.HyperPages = AllocatePages (TransferPages);
> > @@ -121,6 +123,29 @@ XenConnect (
> > mXenHvmloaderInfo = NULL;
> > }
> >
> > + mXenInfo.RsdpPvh = NULL;
> > +
> > + //
> > + // Locate and use information from the start of day structure if we have
> > + // booted via the PVH entry point.
> > + //
> > +
> > + PVHResetVectorData = (VOID *)(UINTN) PcdGet32 (PcdXenPvhStartOfDayStructPtr);
> > + //
> > + // That magic value is written in XenResetVector/Ia32/XenPVHMain.asm
> > + //
> > + if (PVHResetVectorData[1] == SIGNATURE_32 ('X', 'P', 'V', 'H')) {
> > + struct hvm_start_info *HVMStartInfo;
> > +
> > + HVMStartInfo = (VOID *)(UINTN) PVHResetVectorData[0];
> > + if (HVMStartInfo->magic == XEN_HVM_START_MAGIC_VALUE) {
> > + ASSERT (HVMStartInfo->rsdp_paddr != 0);
> > + if (HVMStartInfo->rsdp_paddr != 0) {
> > + mXenInfo.RsdpPvh = (VOID *)(UINTN)HVMStartInfo->rsdp_paddr;
>
> I guess you can do this because OVMF has an identity map of virtual
> addresses to physical addresses?
I think so, yes. I know that early code does created page table like
that, but I don't know if later code rework those page table or not.
> I wonder the size of such identity map, and whether you need to check
> that the rsdp address is indeed inside of that region before
> converting it to a pointer. The same would apply to
> PcdXenPvhStartOfDayStructPtr, but that's likely safe because it's
> always < 4GB, which I assume OVMF always has identity mapped?
PcdXenPvhStartOfDayStructPtr is safe because OVMF owns it. As for the
rspd_paddr* and the HVMStartInfo*, I need to check. As you say, it's
probably fine as long as it's <4GB.
I've looked at the comment here:
https://github.com/tianocore/edk2/blob/master/OvmfPkg/ResetVector/Ia32/PageTables64.asm#L94
This mean that the code executed in the patch (accessing the hvm start
info struct) is executed while the id map is setup up to 4GB. So as long
as the struct is below 4G, it's fine.
As for the RSDP, I think that pointer is accessed much later, when a
different page table is setup, I think that would be that code:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
But I'm not sure how much is setup. But I'm guessing that whatever is
pointed by RSDP, it will be in the 1:1, because we tell the UEFI about
it while parsing the e820.
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 12/35] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
2019-08-08 10:26 ` Anthony PERARD
@ 2019-08-08 10:40 ` Roger Pau Monné
0 siblings, 0 replies; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-08 10:40 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Thu, Aug 08, 2019 at 11:26:41AM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 04:35:58PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:21PM +0100, Anthony PERARD wrote:
> > > Check if there's a start of the day struct provided to PVH guest, save
> > > the ACPI RSDP address for later.
> > >
> > > This patch import import arch-x86/hvm/start_info.h from xen.git.
> >
> > You seem to change the types when importing start_info.h, is that
> > absolutely necessary?
>
> I guess one could try to map xen's types to EDKII's type with typedefs,
> but I'm not sur how well that would work. Importing the xen headers is
> documented so changing the types is fairly easy, see
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Include/IndustryStandard/Xen/README
>
> Also, changing the header further might have been something useful to
> do, we could have match EDKII's naming convention and source files would
> have looked a bit less weird.
Ack, didn't know there was a README for this procedure.
> > From my experience working with different projects when importing such
> > headers it's better to keep them verbatim, this makes importing future
> > versions from upstream easier.
> >
> > I have a comment below, but it's more like a question.
> >
> > > diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> > > index 5c7d7ddc1c..b366139a0a 100644
> > > --- a/OvmfPkg/XenPlatformPei/Xen.c
> > > +++ b/OvmfPkg/XenPlatformPei/Xen.c
> > > @@ -25,6 +25,7 @@
> > > #include <IndustryStandard/E820.h>
> > > #include <Library/ResourcePublicationLib.h>
> > > #include <Library/MtrrLib.h>
> > > +#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
> > >
> > > #include "Platform.h"
> > > #include "Xen.h"
> > > @@ -86,6 +87,7 @@ XenConnect (
> > > UINT32 XenVersion;
> > > EFI_XEN_OVMF_INFO *Info;
> > > CHAR8 Sig[sizeof (Info->Signature) + 1];
> > > + UINT32 *PVHResetVectorData;
> > >
> > > AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
> > > mXenInfo.HyperPages = AllocatePages (TransferPages);
> > > @@ -121,6 +123,29 @@ XenConnect (
> > > mXenHvmloaderInfo = NULL;
> > > }
> > >
> > > + mXenInfo.RsdpPvh = NULL;
> > > +
> > > + //
> > > + // Locate and use information from the start of day structure if we have
> > > + // booted via the PVH entry point.
> > > + //
> > > +
> > > + PVHResetVectorData = (VOID *)(UINTN) PcdGet32 (PcdXenPvhStartOfDayStructPtr);
> > > + //
> > > + // That magic value is written in XenResetVector/Ia32/XenPVHMain.asm
> > > + //
> > > + if (PVHResetVectorData[1] == SIGNATURE_32 ('X', 'P', 'V', 'H')) {
> > > + struct hvm_start_info *HVMStartInfo;
> > > +
> > > + HVMStartInfo = (VOID *)(UINTN) PVHResetVectorData[0];
> > > + if (HVMStartInfo->magic == XEN_HVM_START_MAGIC_VALUE) {
> > > + ASSERT (HVMStartInfo->rsdp_paddr != 0);
> > > + if (HVMStartInfo->rsdp_paddr != 0) {
> > > + mXenInfo.RsdpPvh = (VOID *)(UINTN)HVMStartInfo->rsdp_paddr;
> >
> > I guess you can do this because OVMF has an identity map of virtual
> > addresses to physical addresses?
>
> I think so, yes. I know that early code does created page table like
> that, but I don't know if later code rework those page table or not.
>
> > I wonder the size of such identity map, and whether you need to check
> > that the rsdp address is indeed inside of that region before
> > converting it to a pointer. The same would apply to
> > PcdXenPvhStartOfDayStructPtr, but that's likely safe because it's
> > always < 4GB, which I assume OVMF always has identity mapped?
>
> PcdXenPvhStartOfDayStructPtr is safe because OVMF owns it. As for the
> rspd_paddr* and the HVMStartInfo*, I need to check. As you say, it's
> probably fine as long as it's <4GB.
>
> I've looked at the comment here:
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/ResetVector/Ia32/PageTables64.asm#L94
> This mean that the code executed in the patch (accessing the hvm start
> info struct) is executed while the id map is setup up to 4GB. So as long
> as the struct is below 4G, it's fine.
Yes, the start_info struct is guaranteed to be below 4GB because the
physical memory address of it is passed on a register when starting
the kernel in 32bit protected mode, so the address cannot be greater
than 4GB or it would be truncated.
> As for the RSDP, I think that pointer is accessed much later, when a
> different page table is setup, I think that would be that code:
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> But I'm not sure how much is setup. But I'm guessing that whatever is
> pointed by RSDP, it will be in the 1:1, because we tell the UEFI about
> it while parsing the e820.
OK, as long as we know it's safe to access. Note it's quite likely the
rsdp is also below 4GB anyway, but better be safe than sorry.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 13/35] OvmfPkg/Library/XenPlatformLib: New library
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (11 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 12/35] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 9:57 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 14/35] OvmfPkg/AcpiPlatformDxe: Use XenPlatformLib Anthony PERARD
` (23 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
The purpose of XenPlatformLib is to regroup the few functions that are
used in several places to detect if Xen is detected, and to get the
XenInfo HOB.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- fix top-level comment style
- Update Maintainers.txt
v3:
- use SPDX
- add XenPlatformLib.h to [LibraryClasses] in OvmfPkg.dec
- fix typos
OvmfPkg/OvmfPkg.dec | 4 ++
OvmfPkg/OvmfXen.dsc | 1 +
.../Library/XenPlatformLib/XenPlatformLib.inf | 33 +++++++++
OvmfPkg/Include/Library/XenPlatformLib.h | 53 ++++++++++++++
.../Library/XenPlatformLib/XenPlatformLib.c | 69 +++++++++++++++++++
Maintainers.txt | 2 +
6 files changed, 162 insertions(+)
create mode 100644 OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
create mode 100644 OvmfPkg/Include/Library/XenPlatformLib.h
create mode 100644 OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index c2a2ebfb95..04d5e29272 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -70,6 +70,10 @@ [LibraryClasses]
#
XenIoMmioLib|Include/Library/XenIoMmioLib.h
+ ## @libraryclass Get information about Xen
+ #
+ XenPlatformLib|Include/Library/XenPlatformLib.h
+
[Guids]
gUefiOvmfPkgTokenSpaceGuid = {0x93bb96af, 0xb9f2, 0x4eb8, {0x94, 0x62, 0xe0, 0xba, 0x74, 0x56, 0x42, 0x36}}
gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index b40d39e003..22970eda5d 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -194,6 +194,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
new file mode 100644
index 0000000000..32adb246d6
--- /dev/null
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
@@ -0,0 +1,33 @@
+## @file
+# Get information about Xen
+#
+# This library simply allow to find out if OVMF is running under Xen and
+# allow to get more information when it is the case.
+#
+# Copyright (c) 2019, Citrix Systems, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#
+##
+
+[Defines]
+ INF_VERSION = 0x00010005
+ BASE_NAME = XenPlatformLib
+ FILE_GUID = DB54DBB7-8142-4EE5-9364-78C824B582EB
+ MODULE_TYPE = BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = XenPlatformLib
+
+[Sources]
+ XenPlatformLib.c
+
+[Packages]
+ MdePkg/MdePkg.dec
+ OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+ HobLib
+
+[Guids]
+ gEfiXenInfoGuid
diff --git a/OvmfPkg/Include/Library/XenPlatformLib.h b/OvmfPkg/Include/Library/XenPlatformLib.h
new file mode 100644
index 0000000000..8b8c0d057f
--- /dev/null
+++ b/OvmfPkg/Include/Library/XenPlatformLib.h
@@ -0,0 +1,53 @@
+/** @file
+ Get information about Xen
+
+ This library simply allow to find out if OVMF is running under Xen and
+ allow to get more information when it is the case.
+
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef _XEN_PLATFORM_LIB_H_
+#define _XEN_PLATFORM_LIB_H_
+
+#include <Guid/XenInfo.h>
+
+/**
+ This function detects if OVMF is running on Xen.
+
+ @retval TRUE OVMF is running on Xen
+ @retval FALSE Xen has not been detected
+**/
+BOOLEAN
+EFIAPI
+XenDetected (
+ VOID
+ );
+
+/**
+ This function detect if OVMF have started via the PVH entry point.
+
+ @retval TRUE PVH entry point as been used
+ @retval FALSE OVMF have started via the HVM route
+**/
+BOOLEAN
+EFIAPI
+XenPvhDetected (
+ VOID
+ );
+
+/**
+ This function return a pointer to the XenInfo HOB.
+
+ @return XenInfo pointer or NULL if not available
+**/
+EFI_XEN_INFO *
+EFIAPI
+XenGetInfoHOB (
+ VOID
+ );
+
+#endif
diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
new file mode 100644
index 0000000000..974a0e73f1
--- /dev/null
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
@@ -0,0 +1,69 @@
+/** @file
+ Get information about Xen
+
+ This library simply allow to find out if OVMF is running under Xen and
+ allow to get more information when it is the case.
+
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include <PiDxe.h>
+#include <Library/HobLib.h>
+#include <Library/XenPlatformLib.h>
+
+/**
+ This function return a pointer to the XenInfo HOB.
+
+ @return XenInfo pointer or NULL if not available
+**/
+EFI_XEN_INFO *
+EFIAPI
+XenGetInfoHOB (
+ VOID
+ )
+{
+ EFI_HOB_GUID_TYPE *GuidHob;
+
+ GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
+ if (GuidHob == NULL) {
+ return NULL;
+ }
+
+ return (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
+}
+
+/**
+ This function detects if OVMF is running on Xen.
+
+ @retval TRUE OVMF is running on Xen
+ @retval FALSE Xen has not been detected
+**/
+BOOLEAN
+EFIAPI
+XenDetected (
+ VOID
+ )
+{
+ return (XenGetInfoHOB () != NULL);
+}
+
+/**
+ This function detect if OVMF have started via the PVH entry point.
+
+ @retval TRUE PVH entry point as been used
+ @retval FALSE OVMF have started via the HVM route
+**/
+BOOLEAN
+EFIAPI
+XenPvhDetected (
+ VOID
+ )
+{
+ EFI_XEN_INFO *XenInfo;
+
+ XenInfo = XenGetInfoHOB ();
+ return (XenInfo != NULL && XenInfo->RsdpPvh != NULL);
+}
diff --git a/Maintainers.txt b/Maintainers.txt
index 016523b401..f51731a6b6 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -365,6 +365,7 @@ F: OvmfPkg/Include/Guid/XenInfo.h
F: OvmfPkg/Include/IndustryStandard/Xen/
F: OvmfPkg/Include/Library/XenHypercallLib.h
F: OvmfPkg/Include/Library/XenIoMmioLib.h
+F: OvmfPkg/Include/Library/XenPlatformLib.h
F: OvmfPkg/Include/Protocol/XenBus.h
F: OvmfPkg/Include/Protocol/XenIo.h
F: OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
@@ -372,6 +373,7 @@ F: OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
F: OvmfPkg/Library/XenConsoleSerialPortLib/
F: OvmfPkg/Library/XenHypercallLib/
F: OvmfPkg/Library/XenIoMmioLib/
+F: OvmfPkg/Library/XenPlatformLib/
F: OvmfPkg/OvmfXen.*
F: OvmfPkg/OvmfXenElfHeaderGenerator.c
F: OvmfPkg/PlatformPei/MemDetect.c
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 13/35] OvmfPkg/Library/XenPlatformLib: New library
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 13/35] OvmfPkg/Library/XenPlatformLib: New library Anthony PERARD
@ 2019-07-30 9:57 ` Laszlo Ersek
0 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 9:57 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Jordan Justen
On 07/29/19 17:39, Anthony PERARD wrote:
> The purpose of XenPlatformLib is to regroup the few functions that are
> used in several places to detect if Xen is detected, and to get the
> XenInfo HOB.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - fix top-level comment style
> - Update Maintainers.txt
>
> v3:
> - use SPDX
> - add XenPlatformLib.h to [LibraryClasses] in OvmfPkg.dec
> - fix typos
>
> OvmfPkg/OvmfPkg.dec | 4 ++
> OvmfPkg/OvmfXen.dsc | 1 +
> .../Library/XenPlatformLib/XenPlatformLib.inf | 33 +++++++++
> OvmfPkg/Include/Library/XenPlatformLib.h | 53 ++++++++++++++
> .../Library/XenPlatformLib/XenPlatformLib.c | 69 +++++++++++++++++++
> Maintainers.txt | 2 +
> 6 files changed, 162 insertions(+)
> create mode 100644 OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> create mode 100644 OvmfPkg/Include/Library/XenPlatformLib.h
> create mode 100644 OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
[...]
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 016523b401..f51731a6b6 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -365,6 +365,7 @@ F: OvmfPkg/Include/Guid/XenInfo.h
> F: OvmfPkg/Include/IndustryStandard/Xen/
> F: OvmfPkg/Include/Library/XenHypercallLib.h
> F: OvmfPkg/Include/Library/XenIoMmioLib.h
> +F: OvmfPkg/Include/Library/XenPlatformLib.h
> F: OvmfPkg/Include/Protocol/XenBus.h
> F: OvmfPkg/Include/Protocol/XenIo.h
> F: OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
> @@ -372,6 +373,7 @@ F: OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> F: OvmfPkg/Library/XenConsoleSerialPortLib/
> F: OvmfPkg/Library/XenHypercallLib/
> F: OvmfPkg/Library/XenIoMmioLib/
> +F: OvmfPkg/Library/XenPlatformLib/
> F: OvmfPkg/OvmfXen.*
> F: OvmfPkg/OvmfXenElfHeaderGenerator.c
> F: OvmfPkg/PlatformPei/MemDetect.c
>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 14/35] OvmfPkg/AcpiPlatformDxe: Use XenPlatformLib
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (12 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 13/35] OvmfPkg/Library/XenPlatformLib: New library Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 15/35] OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist Anthony PERARD
` (22 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This patch replace the XenDetected() function by the one in
XenPlatformLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- removed gEfiXenInfoGuid from Guids list.
v3:
- new patch, splited from the next patch
(which was OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist)
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
OvmfPkg/OvmfPkgX64.dsc | 1 +
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 3 +--
OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +-----
OvmfPkg/AcpiPlatformDxe/Xen.c | 24 ---------------------
6 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 6ab7300186..66e944436a 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -200,6 +200,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
!if $(TPM2_ENABLE) == TRUE
Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index f163aa2671..51c2bfb44f 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -205,6 +205,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
!if $(TPM2_ENABLE) == TRUE
Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index fa98f16a3f..ba7a758844 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -205,6 +205,7 @@ [LibraryClasses]
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+ XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
!if $(TPM2_ENABLE) == TRUE
Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 24634eeae2..e486b8afa5 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -44,13 +44,13 @@ [LibraryClasses]
DebugLib
UefiBootServicesTableLib
UefiDriverEntryPoint
- HobLib
QemuFwCfgLib
QemuFwCfgS3Lib
MemoryAllocationLib
BaseLib
DxeServicesTableLib
OrderedCollectionLib
+ XenPlatformLib
[Protocols]
gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
@@ -58,7 +58,6 @@ [Protocols]
gEfiPciIoProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
[Guids]
- gEfiXenInfoGuid
gRootBridgesConnectedEventGroupGuid
[Pcd]
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
index 3037afcf18..9597e028e4 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
@@ -19,6 +19,7 @@
#include <Library/UefiBootServicesTableLib.h>
#include <Library/DebugLib.h>
#include <Library/PcdLib.h>
+#include <Library/XenPlatformLib.h>
#include <IndustryStandard/Acpi.h>
@@ -52,11 +53,6 @@ QemuInstallAcpiTable (
OUT UINTN *TableKey
);
-BOOLEAN
-XenDetected (
- VOID
- );
-
EFI_STATUS
EFIAPI
InstallXenTables (
diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
index e4e47bf0e8..82794b933e 100644
--- a/OvmfPkg/AcpiPlatformDxe/Xen.c
+++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
@@ -9,8 +9,6 @@
**/
#include "AcpiPlatform.h"
-#include <Library/HobLib.h>
-#include <Guid/XenInfo.h>
#include <Library/BaseLib.h>
#define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
@@ -18,28 +16,6 @@
EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr = NULL;
-/**
- This function detects if OVMF is running on Xen.
-
-**/
-BOOLEAN
-XenDetected (
- VOID
- )
-{
- EFI_HOB_GUID_TYPE *GuidHob;
-
- //
- // See if a XenInfo HOB is available
- //
- GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
- if (GuidHob == NULL) {
- return FALSE;
- }
-
- return TRUE;
-}
-
/**
Get the address of Xen ACPI Root System Description Pointer (RSDP)
structure.
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 15/35] OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (13 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 14/35] OvmfPkg/AcpiPlatformDxe: Use XenPlatformLib Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 16/35] OvmfPkg/XenHypercallLib: Enable it in PEIM Anthony PERARD
` (21 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
If the firmware have been started via the Xen PVH entry point, a RSDP
pointer would have been provided. Use it.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- fix coding style
v3:
- patch splited from the previous one
- Fix DEBUG format string, use %p for pointers.
and use gEfiCallerBaseName to print module name
OvmfPkg/AcpiPlatformDxe/Xen.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
index 82794b933e..f80dfe1a57 100644
--- a/OvmfPkg/AcpiPlatformDxe/Xen.c
+++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
@@ -36,10 +36,27 @@ GetXenAcpiRsdp (
EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *RsdpStructurePtr;
UINT8 *XenAcpiPtr;
UINT8 Sum;
+ EFI_XEN_INFO *XenInfo;
//
// Detect the RSDP structure
//
+
+ //
+ // First look for PVH one
+ //
+ XenInfo = XenGetInfoHOB ();
+ ASSERT (XenInfo != NULL);
+ if (XenInfo->RsdpPvh != NULL) {
+ DEBUG ((DEBUG_INFO, "%a: Use ACPI RSDP table at 0x%p\n",
+ gEfiCallerBaseName, XenInfo->RsdpPvh));
+ *RsdpPtr = XenInfo->RsdpPvh;
+ return EFI_SUCCESS;
+ }
+
+ //
+ // Otherwise, look for the HVM one
+ //
for (XenAcpiPtr = (UINT8*)(UINTN) XEN_ACPI_PHYSICAL_ADDRESS;
XenAcpiPtr < (UINT8*)(UINTN) XEN_BIOS_PHYSICAL_END;
XenAcpiPtr += 0x10) {
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 16/35] OvmfPkg/XenHypercallLib: Enable it in PEIM
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (14 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 15/35] OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 17/35] OvmfPkg/XenPlatformPei: Reinit XenHypercallLib Anthony PERARD
` (20 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Allow to use Xen hypercalls earlier, during the PEIM stage, but
XenHypercallLibInit() must be called once the XenInfo HOB is created
with the HyperPage setup.
Change the return value of XenHypercallLibInit so failure can be
detected when the call shouldn't fail, but still have the constructor
always succeed.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- only modify XenHypercallLib, and to the modification of XenPlatformPei
in a separated patch.
- Allow XenHypercallLibInit to be called outside the library instead of
creating a new function, but also return failure on failure,
and have a new constructor that never fail.
.../Library/XenHypercallLib/XenHypercallLib.inf | 4 ++--
OvmfPkg/Include/Library/XenHypercallLib.h | 12 ++++++++++++
.../Library/XenHypercallLib/X86XenHypercall.c | 8 +-------
OvmfPkg/Library/XenHypercallLib/XenHypercall.c | 16 ++++++++++++++++
4 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
index 1208f0057a..21ce5b4434 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
@@ -12,10 +12,10 @@ [Defines]
FILE_GUID = B5EE9A32-CA5A-49A8-82E3-ADA4CCB77C7C
MODULE_TYPE = BASE
VERSION_STRING = 1.0
- CONSTRUCTOR = XenHypercallLibInit
+ CONSTRUCTOR = XenHypercallLibConstruct
[Defines.IA32, Defines.X64]
- LIBRARY_CLASS = XenHypercallLib|DXE_DRIVER UEFI_DRIVER
+ LIBRARY_CLASS = XenHypercallLib|PEIM DXE_DRIVER UEFI_DRIVER
[Defines.ARM, Defines.AARCH64]
LIBRARY_CLASS = XenHypercallLib
diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h b/OvmfPkg/Include/Library/XenHypercallLib.h
index c43822782b..c1491dd652 100644
--- a/OvmfPkg/Include/Library/XenHypercallLib.h
+++ b/OvmfPkg/Include/Library/XenHypercallLib.h
@@ -10,6 +10,18 @@
#ifndef __XEN_HYPERCALL_LIB_H__
#define __XEN_HYPERCALL_LIB_H__
+/**
+ To call when the gEfiXenInfoGuid HOB became available after the library init
+ function has already been executed.
+
+ This allow to make hypercall in the PEIM stage.
+**/
+RETURN_STATUS
+EFIAPI
+XenHypercallLibInit (
+ VOID
+ );
+
/**
Check if the Xen Hypercall library is able to make calls to the Xen
hypervisor.
diff --git a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
index 27083f924f..f779e46470 100644
--- a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
+++ b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
@@ -59,13 +59,7 @@ XenHypercallLibInit (
GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
if (GuidHob == NULL) {
- //
- // We don't fail library construction, since that has catastrophic
- // consequences for client modules (whereas those modules may easily be
- // running on a non-Xen platform). Instead, XenHypercallIsAvailable() above
- // will return FALSE.
- //
- return RETURN_SUCCESS;
+ return RETURN_NOT_FOUND;
}
XenInfo = (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
HyperPage = XenInfo->HyperPages;
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercall.c b/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
index a2c41a2a69..d4fa802743 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
@@ -15,6 +15,22 @@
#include <Library/DebugLib.h>
#include <Library/XenHypercallLib.h>
+RETURN_STATUS
+EFIAPI
+XenHypercallLibConstruct (
+ VOID
+ )
+{
+ XenHypercallLibInit ();
+ //
+ // We don't fail library construction, since that has catastrophic
+ // consequences for client modules (whereas those modules may easily be
+ // running on a non-Xen platform). Instead, XenHypercallIsAvailable()
+ // will return FALSE.
+ //
+ return RETURN_SUCCESS;
+}
+
UINT64
EFIAPI
XenHypercallHvmGetParam (
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 17/35] OvmfPkg/XenPlatformPei: Reinit XenHypercallLib
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (15 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 16/35] OvmfPkg/XenHypercallLib: Enable it in PEIM Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 18/35] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected Anthony PERARD
` (19 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
The XenPlatformPei needs to make hypercalls, but the XenHypercallLib was
initialised before the HyperPage was ready. Now that XenPlatformPei has
initialised the HyperPage, reinitialise the XenHypercallLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- new patch split from XenHypercallLib: Enable it in PEIM.
- check for Lib initialisation failure.
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
OvmfPkg/XenPlatformPei/Xen.c | 9 +++++++++
2 files changed, 10 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 4d00206d09..0ef77db92c 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -59,6 +59,7 @@ [LibraryClasses]
MtrrLib
MemEncryptSevLib
PcdLib
+ XenHypercallLib
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index b366139a0a..c67f4c9697 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -26,6 +26,7 @@
#include <Library/ResourcePublicationLib.h>
#include <Library/MtrrLib.h>
#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
+#include <Library/XenHypercallLib.h>
#include "Platform.h"
#include "Xen.h"
@@ -88,6 +89,7 @@ XenConnect (
EFI_XEN_OVMF_INFO *Info;
CHAR8 Sig[sizeof (Info->Signature) + 1];
UINT32 *PVHResetVectorData;
+ RETURN_STATUS Status;
AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -152,6 +154,13 @@ XenConnect (
sizeof(mXenInfo)
);
+ //
+ // Initialize the XenHypercall library, now that the XenInfo HOB is
+ // available
+ //
+ Status = XenHypercallLibInit ();
+ ASSERT_RETURN_ERROR (Status);
+
return EFI_SUCCESS;
}
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 18/35] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (16 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 17/35] OvmfPkg/XenPlatformPei: Reinit XenHypercallLib Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 19/35] OvmfPkg/XenPlatformPei: Setup HyperPages earlier Anthony PERARD
` (18 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
This new XenHvmloaderDetected() return true if the hvmloader firmware
has runned before OVMF.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- Added one sentence in the commit message.
OvmfPkg/XenPlatformPei/Platform.h | 5 +++++
OvmfPkg/XenPlatformPei/Xen.c | 7 +++++++
2 files changed, 12 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
index 77427496c0..925df31f88 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -89,6 +89,11 @@ XenDetect (
VOID
);
+BOOLEAN
+XenHvmloaderDetected (
+ VOID
+ );
+
VOID
AmdSevInitialize (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index c67f4c9697..2105304c41 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -199,6 +199,13 @@ XenDetect (
return FALSE;
}
+BOOLEAN
+XenHvmloaderDetected (
+ VOID
+ )
+{
+ return (mXenHvmloaderInfo != NULL);
+}
VOID
XenPublishRamRegions (
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 19/35] OvmfPkg/XenPlatformPei: Setup HyperPages earlier
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (17 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 18/35] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected Anthony PERARD
` (17 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
We are going to need to make an hypercall in order to retreive the E820
table from the hypervisor before been able to setup the memory.
Calling XenConnect earlier will allow to setup the XenHypercallLib
earlier to allow to make hypercalls.
While here, add some comments in XenConnect().
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/XenPlatformPei/Platform.h | 5 +++++
OvmfPkg/XenPlatformPei/Platform.c | 2 ++
OvmfPkg/XenPlatformPei/Xen.c | 23 ++++++++++++-----------
3 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
index 925df31f88..4a80057bdc 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -79,6 +79,11 @@ InstallClearCacheCallback (
VOID
);
+EFI_STATUS
+XenConnect (
+ VOID
+ );
+
EFI_STATUS
InitializeXen (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
index 5809eadb0b..6aaafc3ee9 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -416,6 +416,8 @@ InitializeXenPlatform (
CpuDeadLoop ();
}
+ XenConnect ();
+
BootModeInitialization ();
AddressWidthInitialization ();
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 2105304c41..29b42b746c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -72,14 +72,11 @@ XenGetE820Map (
/**
Connects to the Hypervisor.
- @param XenLeaf CPUID index used to connect.
-
@return EFI_STATUS
**/
EFI_STATUS
XenConnect (
- UINT32 XenLeaf
)
{
UINT32 Index;
@@ -91,7 +88,13 @@ XenConnect (
UINT32 *PVHResetVectorData;
RETURN_STATUS Status;
- AsmCpuid (XenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
+ ASSERT (mXenLeaf != 0);
+
+ //
+ // Prepare HyperPages to be able to make hypercalls
+ //
+
+ AsmCpuid (mXenLeaf + 2, &TransferPages, &TransferReg, NULL, NULL);
mXenInfo.HyperPages = AllocatePages (TransferPages);
if (!mXenInfo.HyperPages) {
return EFI_OUT_OF_RESOURCES;
@@ -103,7 +106,11 @@ XenConnect (
(Index << EFI_PAGE_SHIFT) + Index);
}
- AsmCpuid (XenLeaf + 1, &XenVersion, NULL, NULL, NULL);
+ //
+ // Find out the Xen version
+ //
+
+ AsmCpuid (mXenLeaf + 1, &XenVersion, NULL, NULL, NULL);
DEBUG ((DEBUG_ERROR, "Detected Xen version %d.%d\n",
XenVersion >> 16, XenVersion & 0xFFFF));
mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
@@ -262,12 +269,6 @@ InitializeXen (
{
RETURN_STATUS PcdStatus;
- if (mXenLeaf == 0) {
- return EFI_NOT_FOUND;
- }
-
- XenConnect (mXenLeaf);
-
//
// Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
// This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (18 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 19/35] OvmfPkg/XenPlatformPei: Setup HyperPages earlier Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-08-07 15:03 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 21/35] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h Anthony PERARD
` (16 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
XenPvhDetected() can be used to figure out if OVMF has started via the
Xen PVH entry point.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/XenPlatformPei/Platform.h | 5 +++++
OvmfPkg/XenPlatformPei/Xen.c | 13 +++++++++++++
2 files changed, 18 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
index 4a80057bdc..db9a62572f 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -99,6 +99,11 @@ XenHvmloaderDetected (
VOID
);
+BOOLEAN
+XenPvhDetected (
+ VOID
+ );
+
VOID
AmdSevInitialize (
VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 29b42b746c..71fe5de446 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -214,6 +214,19 @@ XenHvmloaderDetected (
return (mXenHvmloaderInfo != NULL);
}
+BOOLEAN
+XenPvhDetected (
+ VOID
+ )
+{
+ //
+ // This function should only be used after XenConnect
+ //
+ ASSERT (mXenInfo.VersionMajor != 0);
+
+ return mXenHvmloaderInfo == NULL;
+}
+
VOID
XenPublishRamRegions (
VOID
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected Anthony PERARD
@ 2019-08-07 15:03 ` Roger Pau Monné
2019-08-08 10:38 ` Anthony PERARD
0 siblings, 1 reply; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 15:03 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Laszlo Ersek, Jordan Justen
On Mon, Jul 29, 2019 at 04:39:29PM +0100, Anthony PERARD wrote:
> XenPvhDetected() can be used to figure out if OVMF has started via the
> Xen PVH entry point.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
Thanks, I've got a comment, but it can be fixed afterwards if required.
> ---
> OvmfPkg/XenPlatformPei/Platform.h | 5 +++++
> OvmfPkg/XenPlatformPei/Xen.c | 13 +++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
> index 4a80057bdc..db9a62572f 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -99,6 +99,11 @@ XenHvmloaderDetected (
> VOID
> );
>
> +BOOLEAN
> +XenPvhDetected (
> + VOID
> + );
> +
> VOID
> AmdSevInitialize (
> VOID
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 29b42b746c..71fe5de446 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -214,6 +214,19 @@ XenHvmloaderDetected (
> return (mXenHvmloaderInfo != NULL);
> }
>
> +BOOLEAN
> +XenPvhDetected (
> + VOID
> + )
> +{
> + //
> + // This function should only be used after XenConnect
> + //
> + ASSERT (mXenInfo.VersionMajor != 0);
That's IMO dangerous. Using the version as an indication that
XenConnect has run seems like a bad idea, since returning a major
version of 0 is a valid number to return. Can't you check against
something else that doesn't depends on hypervisor provided data? (ie:
like some allocations or such that happen in XenConnect)
A paranoid could provider could even return major == 0 and minor == 0
in order to attempt to hide the Xen version used, since guests are not
supposed to infer anything from the Xen version, available hypervisor
features are reported by other means.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
2019-08-07 15:03 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
@ 2019-08-08 10:38 ` Anthony PERARD
2019-08-08 10:43 ` Roger Pau Monné
0 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-08-08 10:38 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Wed, Aug 07, 2019 at 05:03:46PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:29PM +0100, Anthony PERARD wrote:
> > +BOOLEAN
> > +XenPvhDetected (
> > + VOID
> > + )
> > +{
> > + //
> > + // This function should only be used after XenConnect
> > + //
> > + ASSERT (mXenInfo.VersionMajor != 0);
>
> That's IMO dangerous. Using the version as an indication that
> XenConnect has run seems like a bad idea, since returning a major
> version of 0 is a valid number to return. Can't you check against
> something else that doesn't depends on hypervisor provided data? (ie:
> like some allocations or such that happen in XenConnect)
>
> A paranoid could provider could even return major == 0 and minor == 0
> in order to attempt to hide the Xen version used, since guests are not
> supposed to infer anything from the Xen version, available hypervisor
> features are reported by other means.
I'm sure a paranoid provider wouldn't use a debug build of OVMF :-). So
that assert doesn't matter. There's nothing dangerous in a `nop'! :-D
But I could use mXenInfo.HyperPages instead.
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
2019-08-08 10:38 ` Anthony PERARD
@ 2019-08-08 10:43 ` Roger Pau Monné
0 siblings, 0 replies; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-08 10:43 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Thu, Aug 08, 2019 at 11:38:13AM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 05:03:46PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:29PM +0100, Anthony PERARD wrote:
> > > +BOOLEAN
> > > +XenPvhDetected (
> > > + VOID
> > > + )
> > > +{
> > > + //
> > > + // This function should only be used after XenConnect
> > > + //
> > > + ASSERT (mXenInfo.VersionMajor != 0);
> >
> > That's IMO dangerous. Using the version as an indication that
> > XenConnect has run seems like a bad idea, since returning a major
> > version of 0 is a valid number to return. Can't you check against
> > something else that doesn't depends on hypervisor provided data? (ie:
> > like some allocations or such that happen in XenConnect)
> >
> > A paranoid could provider could even return major == 0 and minor == 0
> > in order to attempt to hide the Xen version used, since guests are not
> > supposed to infer anything from the Xen version, available hypervisor
> > features are reported by other means.
>
> I'm sure a paranoid provider wouldn't use a debug build of OVMF :-). So
> that assert doesn't matter. There's nothing dangerous in a `nop'! :-D
>
> But I could use mXenInfo.HyperPages instead.
It's just a nit, and TBH it's quite unlikely for anyone to report a
major version of 0, it's just that if you have something else to
assert for initialization it might be safer.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 21/35] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (19 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 22/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall Anthony PERARD
` (15 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
The informations to make a XENMEM_memory_map hypercall is copied over
from the public header of the Xen Project, with the type name modified
to build on OVMF.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- expanded the "This" that was starting the commit message body.
OvmfPkg/Include/IndustryStandard/Xen/memory.h | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/memory.h b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
index 81e981331a..4a33a26d4e 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/memory.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
@@ -65,6 +65,29 @@ struct xen_remove_from_physmap {
typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+/*
+ * Returns the pseudo-physical memory map as it was when the domain
+ * was started (specified by XENMEM_set_memory_map).
+ * arg == addr of xen_memory_map_t.
+ */
+#define XENMEM_memory_map 9
+struct xen_memory_map {
+ /*
+ * On call the number of entries which can be stored in buffer. On
+ * return the number of entries which have been stored in
+ * buffer.
+ */
+ UINT32 nr_entries;
+
+ /*
+ * Entries in the buffer are in the same format as returned by the
+ * BIOS INT 0x15 EAX=0xE820 call.
+ */
+ XEN_GUEST_HANDLE(void) buffer;
+};
+typedef struct xen_memory_map xen_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_memory_map_t);
+
#endif /* __XEN_PUBLIC_MEMORY_H__ */
/*
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 22/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (20 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 21/35] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-08-07 15:14 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 23/35] OvmfPkg/XenPlatformPei: Rework memory detection Anthony PERARD
` (14 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
When the Xen PVH entry point has been used, hvmloader hasn't run and
hasn't prepared an E820 table. The only way left to get an E820 table
is to ask Xen via an hypercall, the call can only be made once so keep
the result cached for later.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- fix commit message
- add 'm' prefix to the global variables
and make them static
OvmfPkg/XenPlatformPei/Xen.c | 46 +++++++++++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 71fe5de446..a21d657357 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -27,6 +27,7 @@
#include <Library/MtrrLib.h>
#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
#include <Library/XenHypercallLib.h>
+#include <IndustryStandard/Xen/memory.h>
#include "Platform.h"
#include "Xen.h"
@@ -40,6 +41,8 @@ EFI_XEN_INFO mXenInfo;
// Only the E820 table is used by OVMF.
//
EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
+STATIC EFI_E820_ENTRY64 mE820Entries[128];
+STATIC UINT32 mE820EntriesCount;
/**
Returns E820 map provided by Xen
@@ -55,6 +58,12 @@ XenGetE820Map (
UINT32 *Count
)
{
+ INTN ReturnCode;
+ xen_memory_map_t Parameters;
+ UINTN LoopIndex;
+ UINTN Index;
+ EFI_E820_ENTRY64 TmpEntry;
+
//
// Get E820 produced by hvmloader
//
@@ -66,7 +75,42 @@ XenGetE820Map (
return EFI_SUCCESS;
}
- return EFI_NOT_FOUND;
+ //
+ // Otherwise, get the E820 table from the Xen hypervisor
+ //
+
+ if (mE820EntriesCount > 0) {
+ *Entries = mE820Entries;
+ *Count = mE820EntriesCount;
+ return EFI_SUCCESS;
+ }
+
+ Parameters.nr_entries = 128;
+ set_xen_guest_handle (Parameters.buffer, mE820Entries);
+
+ // Returns a errno
+ ReturnCode = XenHypercallMemoryOp (XENMEM_memory_map, &Parameters);
+ ASSERT (ReturnCode == 0);
+
+ mE820EntriesCount = Parameters.nr_entries;
+
+ //
+ // Sort E820 entries
+ //
+ for (LoopIndex = 1; LoopIndex < mE820EntriesCount; LoopIndex++) {
+ for (Index = LoopIndex; Index < mE820EntriesCount; Index++) {
+ if (mE820Entries[Index - 1].BaseAddr > mE820Entries[Index].BaseAddr) {
+ TmpEntry = mE820Entries[Index];
+ mE820Entries[Index] = mE820Entries[Index - 1];
+ mE820Entries[Index - 1] = TmpEntry;
+ }
+ }
+ }
+
+ *Count = mE820EntriesCount;
+ *Entries = mE820Entries;
+
+ return EFI_SUCCESS;
}
/**
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 22/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 22/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall Anthony PERARD
@ 2019-08-07 15:14 ` Roger Pau Monné
2019-08-08 10:41 ` Anthony PERARD
0 siblings, 1 reply; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 15:14 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Laszlo Ersek, Jordan Justen
On Mon, Jul 29, 2019 at 04:39:31PM +0100, Anthony PERARD wrote:
> When the Xen PVH entry point has been used, hvmloader hasn't run and
> hasn't prepared an E820 table. The only way left to get an E820 table
> is to ask Xen via an hypercall, the call can only be made once so keep
> the result cached for later.
I think we agreed that the above is not true, and that the memory
map can be fetched as many times as desired using the hypercall
interface.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 22/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall
2019-08-07 15:14 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
@ 2019-08-08 10:41 ` Anthony PERARD
2019-08-08 10:45 ` Roger Pau Monné
0 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-08-08 10:41 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Wed, Aug 07, 2019 at 05:14:33PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:31PM +0100, Anthony PERARD wrote:
> > When the Xen PVH entry point has been used, hvmloader hasn't run and
> > hasn't prepared an E820 table. The only way left to get an E820 table
> > is to ask Xen via an hypercall, the call can only be made once so keep
> > the result cached for later.
>
> I think we agreed that the above is not true, and that the memory
> map can be fetched as many times as desired using the hypercall
> interface.
Yes, I'll change the commit message. How about:
When the Xen PVH entry point has been used, hvmloader hasn't run and
hasn't prepared an E820 table. The only way left to get an E820 table
is to ask Xen via an hypercall. We keep the result cached to avoid
making a second hypercall which would give the same result.
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 22/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall
2019-08-08 10:41 ` Anthony PERARD
@ 2019-08-08 10:45 ` Roger Pau Monné
0 siblings, 0 replies; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-08 10:45 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Thu, Aug 08, 2019 at 11:41:18AM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 05:14:33PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:31PM +0100, Anthony PERARD wrote:
> > > When the Xen PVH entry point has been used, hvmloader hasn't run and
> > > hasn't prepared an E820 table. The only way left to get an E820 table
> > > is to ask Xen via an hypercall, the call can only be made once so keep
> > > the result cached for later.
> >
> > I think we agreed that the above is not true, and that the memory
> > map can be fetched as many times as desired using the hypercall
> > interface.
>
> Yes, I'll change the commit message. How about:
>
> When the Xen PVH entry point has been used, hvmloader hasn't run and
> hasn't prepared an E820 table. The only way left to get an E820 table
> is to ask Xen via an hypercall. We keep the result cached to avoid
> making a second hypercall which would give the same result.
LGTM, thanks.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 23/35] OvmfPkg/XenPlatformPei: Rework memory detection
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (21 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 22/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 11:45 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-08-07 15:34 ` [Xen-devel] " Roger Pau Monné
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 24/35] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux Anthony PERARD
` (13 subsequent siblings)
36 siblings, 2 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Andrew Cooper,
Anthony PERARD, xen-devel, Laszlo Ersek, Roger Pau Monné
When running as a Xen PVH guest, there is no CMOS to read the memory
size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
work without CMOS by reading the e820 table.
Rework XenPublishRamRegions to also care for the reserved and ACPI
entry in the e820 table. The region that was added by InitializeXen()
isn't needed as that same entry is in the e820 table provided by
hvmloader.
MTRR settings aren't modified anymore, on HVM it's already done by
hvmloader, on PVH it is supposed to have sane default. MTRR will need
to be done properly but keeping what's already been done by programmes
that has runned before OVMF will do for now.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- some coding style
- Added AddReservedMemoryRangeHob, and using it.
- this patch now replace "OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it has run"
from v3. hvmloader have added an entry in the e820 table, there is no
need for a special case.
- now, everything that is in the e820 table is added to OVMF's memory
map, no more skipping ACPI entries or hvmloader's reserved entries.
Instead, we look for the local APIC region and avoid it if it is
present in the e820.
- rework commit message
OvmfPkg/XenPlatformPei/Platform.h | 13 ++++++
OvmfPkg/XenPlatformPei/MemDetect.c | 69 +++++++++++++++++++++++++++++
OvmfPkg/XenPlatformPei/Platform.c | 11 +++++
OvmfPkg/XenPlatformPei/Xen.c | 70 +++++++++++++++++++-----------
4 files changed, 137 insertions(+), 26 deletions(-)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
index db9a62572f..7661f4a8de 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -44,6 +44,13 @@ AddReservedMemoryBaseSizeHob (
BOOLEAN Cacheable
);
+VOID
+AddReservedMemoryRangeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ EFI_PHYSICAL_ADDRESS MemoryLimit,
+ BOOLEAN Cacheable
+ );
+
VOID
AddressWidthInitialization (
VOID
@@ -114,6 +121,12 @@ XenPublishRamRegions (
VOID
);
+EFI_STATUS
+XenGetE820Map (
+ EFI_E820_ENTRY64 **Entries,
+ UINT32 *Count
+ );
+
extern EFI_BOOT_MODE mBootMode;
extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c b/OvmfPkg/XenPlatformPei/MemDetect.c
index cf95f9c474..1f81eee407 100644
--- a/OvmfPkg/XenPlatformPei/MemDetect.c
+++ b/OvmfPkg/XenPlatformPei/MemDetect.c
@@ -96,6 +96,45 @@ Q35TsegMbytesInitialization (
mQ35TsegMbytes = ExtendedTsegMbytes;
}
+STATIC
+UINT64
+GetHighestSystemMemoryAddress (
+ BOOLEAN Below4gb
+ )
+{
+ EFI_E820_ENTRY64 *E820Map;
+ UINT32 E820EntriesCount;
+ EFI_E820_ENTRY64 *Entry;
+ EFI_STATUS Status;
+ UINT32 Loop;
+ UINT64 HighestAddress;
+ UINT64 EntryEnd;
+
+ HighestAddress = 0;
+
+ Status = XenGetE820Map (&E820Map, &E820EntriesCount);
+ ASSERT_EFI_ERROR (Status);
+
+ for (Loop = 0; Loop < E820EntriesCount; Loop++) {
+ Entry = E820Map + Loop;
+ EntryEnd = Entry->BaseAddr + Entry->Length;
+
+ if (Entry->Type == EfiAcpiAddressRangeMemory &&
+ EntryEnd > HighestAddress) {
+
+ if (Below4gb && (EntryEnd <= BASE_4GB)) {
+ HighestAddress = EntryEnd;
+ } else if (!Below4gb && (EntryEnd >= BASE_4GB)) {
+ HighestAddress = EntryEnd;
+ }
+ }
+ }
+
+ //
+ // Round down the end address.
+ //
+ return HighestAddress & ~(UINT64)EFI_PAGE_MASK;
+}
UINT32
GetSystemMemorySizeBelow4gb (
@@ -105,6 +144,19 @@ GetSystemMemorySizeBelow4gb (
UINT8 Cmos0x34;
UINT8 Cmos0x35;
+ //
+ // In PVH case, there is no CMOS, we have to calculate the memory size
+ // from parsing the E820
+ //
+ if (XenPvhDetected ()) {
+ UINT64 HighestAddress;
+
+ HighestAddress = GetHighestSystemMemoryAddress (TRUE);
+ ASSERT (HighestAddress > 0 && HighestAddress <= BASE_4GB);
+
+ return HighestAddress;
+ }
+
//
// CMOS 0x34/0x35 specifies the system memory above 16 MB.
// * CMOS(0x35) is the high byte
@@ -129,6 +181,23 @@ GetSystemMemorySizeAbove4gb (
UINT32 Size;
UINTN CmosIndex;
+ //
+ // In PVH case, there is no CMOS, we have to calculate the memory size
+ // from parsing the E820
+ //
+ if (XenPvhDetected ()) {
+ UINT64 HighestAddress;
+
+ HighestAddress = GetHighestSystemMemoryAddress (FALSE);
+ ASSERT (HighestAddress == 0 || HighestAddress >= BASE_4GB);
+
+ if (HighestAddress >= BASE_4GB) {
+ HighestAddress -= BASE_4GB;
+ }
+
+ return HighestAddress;
+ }
+
//
// CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
// * CMOS(0x5d) is the most significant size byte
diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
index 6aaafc3ee9..2f42ca6ccd 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -102,6 +102,17 @@ AddReservedMemoryBaseSizeHob (
);
}
+VOID
+AddReservedMemoryRangeHob (
+ EFI_PHYSICAL_ADDRESS MemoryBase,
+ EFI_PHYSICAL_ADDRESS MemoryLimit,
+ BOOLEAN Cacheable
+ )
+{
+ AddReservedMemoryBaseSizeHob (MemoryBase,
+ (UINT64)(MemoryLimit - MemoryBase), Cacheable);
+}
+
VOID
AddIoMemoryRangeHob (
EFI_PHYSICAL_ADDRESS MemoryBase,
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index a21d657357..182e96cc5b 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -276,9 +276,12 @@ XenPublishRamRegions (
VOID
)
{
- EFI_E820_ENTRY64 *E820Map;
- UINT32 E820EntriesCount;
- EFI_STATUS Status;
+ EFI_E820_ENTRY64 *E820Map;
+ UINT32 E820EntriesCount;
+ EFI_STATUS Status;
+ EFI_E820_ENTRY64 *Entry;
+ UINTN Index;
+ EFI_PHYSICAL_ADDRESS LocalApic;
DEBUG ((DEBUG_INFO, "Using memory map provided by Xen\n"));
@@ -287,26 +290,47 @@ XenPublishRamRegions (
//
E820EntriesCount = 0;
Status = XenGetE820Map (&E820Map, &E820EntriesCount);
-
ASSERT_EFI_ERROR (Status);
- if (E820EntriesCount > 0) {
- EFI_E820_ENTRY64 *Entry;
- UINT32 Loop;
-
- for (Loop = 0; Loop < E820EntriesCount; Loop++) {
- Entry = E820Map + Loop;
-
- //
- // Only care about RAM
- //
- if (Entry->Type != EfiAcpiAddressRangeMemory) {
- continue;
+ LocalApic = PcdGet32(PcdCpuLocalApicBaseAddress);
+ AddIoMemoryBaseSizeHob (LocalApic, SIZE_1MB);
+
+ for (Index = 0; Index < E820EntriesCount; Index++) {
+ UINT64 Base;
+ UINT64 End;
+
+ Entry = &E820Map[Index];
+
+ //
+ // Round up the start address, and round down the end address.
+ //
+ Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
+ End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
+
+ switch (Entry->Type) {
+ case EfiAcpiAddressRangeMemory:
+ AddMemoryRangeHob (Base, End);
+ break;
+ case EfiAcpiAddressRangeACPI:
+ AddReservedMemoryRangeHob (Base, End, FALSE);
+ break;
+ case EfiAcpiAddressRangeReserved:
+ if (Base < LocalApic && LocalApic < End) {
+ //
+ // hvmloader marks a range that overlaps with the local APIC memory
+ // mapped region as reserved, but CpuDxe wants it as mapped IO. We
+ // have already added it as mapped IO, so skip it here.
+ //
+ AddReservedMemoryRangeHob (Base, LocalApic, FALSE);
+ if (End > (LocalApic + SIZE_1MB)) {
+ AddReservedMemoryRangeHob (LocalApic + SIZE_1MB, End, FALSE);
+ }
+ } else {
+ AddReservedMemoryRangeHob (Base, End, FALSE);
}
-
- AddMemoryBaseSizeHob (Entry->BaseAddr, Entry->Length);
-
- MtrrSetMemoryAttribute (Entry->BaseAddr, Entry->Length, CacheWriteBack);
+ break;
+ default:
+ break;
}
}
}
@@ -326,12 +350,6 @@ InitializeXen (
{
RETURN_STATUS PcdStatus;
- //
- // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
- // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
- //
- AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
-
PcdStatus = PcdSetBoolS (PcdPciDisableBusEnumeration, TRUE);
ASSERT_RETURN_ERROR (PcdStatus);
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 23/35] OvmfPkg/XenPlatformPei: Rework memory detection
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 23/35] OvmfPkg/XenPlatformPei: Rework memory detection Anthony PERARD
@ 2019-07-30 11:45 ` Laszlo Ersek
2019-07-30 12:18 ` Laszlo Ersek
2019-08-07 15:34 ` [Xen-devel] " Roger Pau Monné
1 sibling, 1 reply; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 11:45 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Ard Biesheuvel, Andrew Cooper, Julien Grall, Jordan Justen,
xen-devel, Roger Pau Monné
On 07/29/19 17:39, Anthony PERARD wrote:
> When running as a Xen PVH guest, there is no CMOS to read the memory
> size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
> work without CMOS by reading the e820 table.
>
> Rework XenPublishRamRegions to also care for the reserved and ACPI
> entry in the e820 table. The region that was added by InitializeXen()
> isn't needed as that same entry is in the e820 table provided by
> hvmloader.
>
> MTRR settings aren't modified anymore, on HVM it's already done by
> hvmloader, on PVH it is supposed to have sane default. MTRR will need
> to be done properly but keeping what's already been done by programmes
> that has runned before OVMF will do for now.
(1) s/programmes that has runned/programs that have run/
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - some coding style
> - Added AddReservedMemoryRangeHob, and using it.
> - this patch now replace "OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it has run"
> from v3. hvmloader have added an entry in the e820 table, there is no
> need for a special case.
> - now, everything that is in the e820 table is added to OVMF's memory
> map, no more skipping ACPI entries or hvmloader's reserved entries.
> Instead, we look for the local APIC region and avoid it if it is
> present in the e820.
> - rework commit message
>
> OvmfPkg/XenPlatformPei/Platform.h | 13 ++++++
> OvmfPkg/XenPlatformPei/MemDetect.c | 69 +++++++++++++++++++++++++++++
> OvmfPkg/XenPlatformPei/Platform.c | 11 +++++
> OvmfPkg/XenPlatformPei/Xen.c | 70 +++++++++++++++++++-----------
> 4 files changed, 137 insertions(+), 26 deletions(-)
>
> diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
> index db9a62572f..7661f4a8de 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -44,6 +44,13 @@ AddReservedMemoryBaseSizeHob (
> BOOLEAN Cacheable
> );
>
> +VOID
> +AddReservedMemoryRangeHob (
> + EFI_PHYSICAL_ADDRESS MemoryBase,
> + EFI_PHYSICAL_ADDRESS MemoryLimit,
> + BOOLEAN Cacheable
> + );
> +
> VOID
> AddressWidthInitialization (
> VOID
> @@ -114,6 +121,12 @@ XenPublishRamRegions (
> VOID
> );
>
> +EFI_STATUS
> +XenGetE820Map (
> + EFI_E820_ENTRY64 **Entries,
> + UINT32 *Count
> + );
> +
> extern EFI_BOOT_MODE mBootMode;
>
> extern UINT8 mPhysMemAddressWidth;
> diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c b/OvmfPkg/XenPlatformPei/MemDetect.c
> index cf95f9c474..1f81eee407 100644
> --- a/OvmfPkg/XenPlatformPei/MemDetect.c
> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
> @@ -96,6 +96,45 @@ Q35TsegMbytesInitialization (
> mQ35TsegMbytes = ExtendedTsegMbytes;
> }
>
> +STATIC
> +UINT64
> +GetHighestSystemMemoryAddress (
> + BOOLEAN Below4gb
> + )
> +{
> + EFI_E820_ENTRY64 *E820Map;
> + UINT32 E820EntriesCount;
> + EFI_E820_ENTRY64 *Entry;
> + EFI_STATUS Status;
> + UINT32 Loop;
> + UINT64 HighestAddress;
> + UINT64 EntryEnd;
> +
> + HighestAddress = 0;
> +
> + Status = XenGetE820Map (&E820Map, &E820EntriesCount);
> + ASSERT_EFI_ERROR (Status);
> +
> + for (Loop = 0; Loop < E820EntriesCount; Loop++) {
> + Entry = E820Map + Loop;
> + EntryEnd = Entry->BaseAddr + Entry->Length;
> +
> + if (Entry->Type == EfiAcpiAddressRangeMemory &&
> + EntryEnd > HighestAddress) {
> +
> + if (Below4gb && (EntryEnd <= BASE_4GB)) {
> + HighestAddress = EntryEnd;
> + } else if (!Below4gb && (EntryEnd >= BASE_4GB)) {
> + HighestAddress = EntryEnd;
> + }
> + }
> + }
> +
> + //
> + // Round down the end address.
> + //
> + return HighestAddress & ~(UINT64)EFI_PAGE_MASK;
> +}
>
> UINT32
> GetSystemMemorySizeBelow4gb (
> @@ -105,6 +144,19 @@ GetSystemMemorySizeBelow4gb (
> UINT8 Cmos0x34;
> UINT8 Cmos0x35;
>
> + //
> + // In PVH case, there is no CMOS, we have to calculate the memory size
> + // from parsing the E820
> + //
> + if (XenPvhDetected ()) {
> + UINT64 HighestAddress;
> +
> + HighestAddress = GetHighestSystemMemoryAddress (TRUE);
> + ASSERT (HighestAddress > 0 && HighestAddress <= BASE_4GB);
> +
> + return HighestAddress;
> + }
> +
> //
> // CMOS 0x34/0x35 specifies the system memory above 16 MB.
> // * CMOS(0x35) is the high byte
> @@ -129,6 +181,23 @@ GetSystemMemorySizeAbove4gb (
> UINT32 Size;
> UINTN CmosIndex;
>
> + //
> + // In PVH case, there is no CMOS, we have to calculate the memory size
> + // from parsing the E820
> + //
> + if (XenPvhDetected ()) {
> + UINT64 HighestAddress;
> +
> + HighestAddress = GetHighestSystemMemoryAddress (FALSE);
> + ASSERT (HighestAddress == 0 || HighestAddress >= BASE_4GB);
> +
> + if (HighestAddress >= BASE_4GB) {
> + HighestAddress -= BASE_4GB;
> + }
> +
> + return HighestAddress;
> + }
> +
> //
> // CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
> // * CMOS(0x5d) is the most significant size byte
> diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
> index 6aaafc3ee9..2f42ca6ccd 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -102,6 +102,17 @@ AddReservedMemoryBaseSizeHob (
> );
> }
>
> +VOID
> +AddReservedMemoryRangeHob (
> + EFI_PHYSICAL_ADDRESS MemoryBase,
> + EFI_PHYSICAL_ADDRESS MemoryLimit,
> + BOOLEAN Cacheable
> + )
> +{
> + AddReservedMemoryBaseSizeHob (MemoryBase,
> + (UINT64)(MemoryLimit - MemoryBase), Cacheable);
> +}
> +
> VOID
> AddIoMemoryRangeHob (
> EFI_PHYSICAL_ADDRESS MemoryBase,
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index a21d657357..182e96cc5b 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -276,9 +276,12 @@ XenPublishRamRegions (
> VOID
> )
> {
> - EFI_E820_ENTRY64 *E820Map;
> - UINT32 E820EntriesCount;
> - EFI_STATUS Status;
> + EFI_E820_ENTRY64 *E820Map;
> + UINT32 E820EntriesCount;
> + EFI_STATUS Status;
> + EFI_E820_ENTRY64 *Entry;
> + UINTN Index;
> + EFI_PHYSICAL_ADDRESS LocalApic;
>
> DEBUG ((DEBUG_INFO, "Using memory map provided by Xen\n"));
>
> @@ -287,26 +290,47 @@ XenPublishRamRegions (
> //
> E820EntriesCount = 0;
> Status = XenGetE820Map (&E820Map, &E820EntriesCount);
> -
> ASSERT_EFI_ERROR (Status);
>
> - if (E820EntriesCount > 0) {
> - EFI_E820_ENTRY64 *Entry;
> - UINT32 Loop;
> -
> - for (Loop = 0; Loop < E820EntriesCount; Loop++) {
> - Entry = E820Map + Loop;
> -
> - //
> - // Only care about RAM
> - //
> - if (Entry->Type != EfiAcpiAddressRangeMemory) {
> - continue;
> + LocalApic = PcdGet32(PcdCpuLocalApicBaseAddress);
(2) missing space before "(" -- but, actually, please see below
> + AddIoMemoryBaseSizeHob (LocalApic, SIZE_1MB);
> +
> + for (Index = 0; Index < E820EntriesCount; Index++) {
> + UINT64 Base;
> + UINT64 End;
> +
> + Entry = &E820Map[Index];
> +
> + //
> + // Round up the start address, and round down the end address.
> + //
> + Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
> + End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
> +
> + switch (Entry->Type) {
> + case EfiAcpiAddressRangeMemory:
> + AddMemoryRangeHob (Base, End);
> + break;
> + case EfiAcpiAddressRangeACPI:
> + AddReservedMemoryRangeHob (Base, End, FALSE);
> + break;
> + case EfiAcpiAddressRangeReserved:
> + if (Base < LocalApic && LocalApic < End) {
> + //
> + // hvmloader marks a range that overlaps with the local APIC memory
> + // mapped region as reserved, but CpuDxe wants it as mapped IO. We
> + // have already added it as mapped IO, so skip it here.
> + //
> + AddReservedMemoryRangeHob (Base, LocalApic, FALSE);
> + if (End > (LocalApic + SIZE_1MB)) {
> + AddReservedMemoryRangeHob (LocalApic + SIZE_1MB, End, FALSE);
> + }
> + } else {
> + AddReservedMemoryRangeHob (Base, End, FALSE);
> }
(3) Not sure how general you want to be here, but I don't think this is
fully general. How about:
(3a) before the loop, drop "LocalApic", and add:
UINT64 LapicBase;
UINT64 LapicEnd;
LapicBase = PcdGet32 (PcdCpuLocalApicBaseAddress);
LapicEnd = LapicBase + SIZE_1MB;
(3b) inside the loop body, near the top of the block, add:
UINT64 ReservedBase;
UINT64 ReservedEnd;
(3c) under the EfiAcpiAddressRangeReserved case label:
//
// add LAPIC predecessor range, if any
//
ReservedBase = Base;
ReservedEnd = MIN (End, LapicBase);
if (ReservedBase < ReservedEnd) {
AddReservedMemoryRangeHob (ReservedBase, ReservedEnd, FALSE);
}
//
// add LAPIC successor range, if any
//
ReservedBase = MAX (Base, LapicEnd);
ReservedEnd = End;
if (ReservedBase < ReservedEnd) {
AddReservedMemoryRangeHob (ReservedBase, ReservedEnd, FALSE);
}
This will cover all possible constellations between the [LapicBase,
LapicEnd) and [Base, End) intervals.
--*--
Regarding the approach itself, I'll defer to Roger.
Thanks
Laszlo
> -
> - AddMemoryBaseSizeHob (Entry->BaseAddr, Entry->Length);
> -
> - MtrrSetMemoryAttribute (Entry->BaseAddr, Entry->Length, CacheWriteBack);
> + break;
> + default:
> + break;
> }
> }
> }
> @@ -326,12 +350,6 @@ InitializeXen (
> {
> RETURN_STATUS PcdStatus;
>
> - //
> - // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
> - // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
> - //
> - AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
> -
> PcdStatus = PcdSetBoolS (PcdPciDisableBusEnumeration, TRUE);
> ASSERT_RETURN_ERROR (PcdStatus);
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 23/35] OvmfPkg/XenPlatformPei: Rework memory detection
2019-07-30 11:45 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
@ 2019-07-30 12:18 ` Laszlo Ersek
0 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 12:18 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Ard Biesheuvel, Andrew Cooper, Julien Grall, Jordan Justen,
xen-devel, Roger Pau Monné
On 07/30/19 13:45, Laszlo Ersek wrote:
> On 07/29/19 17:39, Anthony PERARD wrote:
>> When running as a Xen PVH guest, there is no CMOS to read the memory
>> size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
>> work without CMOS by reading the e820 table.
>>
>> Rework XenPublishRamRegions to also care for the reserved and ACPI
>> entry in the e820 table. The region that was added by InitializeXen()
>> isn't needed as that same entry is in the e820 table provided by
>> hvmloader.
>>
>> MTRR settings aren't modified anymore, on HVM it's already done by
>> hvmloader, on PVH it is supposed to have sane default. MTRR will need
>> to be done properly but keeping what's already been done by programmes
>> that has runned before OVMF will do for now.
>
> (1) s/programmes that has runned/programs that have run/
>
>>
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> Acked-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> v4:
>> - some coding style
>> - Added AddReservedMemoryRangeHob, and using it.
>> - this patch now replace "OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it has run"
>> from v3. hvmloader have added an entry in the e820 table, there is no
>> need for a special case.
>> - now, everything that is in the e820 table is added to OVMF's memory
>> map, no more skipping ACPI entries or hvmloader's reserved entries.
>> Instead, we look for the local APIC region and avoid it if it is
>> present in the e820.
>> - rework commit message
>>
>> OvmfPkg/XenPlatformPei/Platform.h | 13 ++++++
>> OvmfPkg/XenPlatformPei/MemDetect.c | 69 +++++++++++++++++++++++++++++
>> OvmfPkg/XenPlatformPei/Platform.c | 11 +++++
>> OvmfPkg/XenPlatformPei/Xen.c | 70 +++++++++++++++++++-----------
>> 4 files changed, 137 insertions(+), 26 deletions(-)
>>
>> diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h
>> index db9a62572f..7661f4a8de 100644
>> --- a/OvmfPkg/XenPlatformPei/Platform.h
>> +++ b/OvmfPkg/XenPlatformPei/Platform.h
>> @@ -44,6 +44,13 @@ AddReservedMemoryBaseSizeHob (
>> BOOLEAN Cacheable
>> );
>>
>> +VOID
>> +AddReservedMemoryRangeHob (
>> + EFI_PHYSICAL_ADDRESS MemoryBase,
>> + EFI_PHYSICAL_ADDRESS MemoryLimit,
>> + BOOLEAN Cacheable
>> + );
>> +
>> VOID
>> AddressWidthInitialization (
>> VOID
>> @@ -114,6 +121,12 @@ XenPublishRamRegions (
>> VOID
>> );
>>
>> +EFI_STATUS
>> +XenGetE820Map (
>> + EFI_E820_ENTRY64 **Entries,
>> + UINT32 *Count
>> + );
>> +
>> extern EFI_BOOT_MODE mBootMode;
>>
>> extern UINT8 mPhysMemAddressWidth;
>> diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c b/OvmfPkg/XenPlatformPei/MemDetect.c
>> index cf95f9c474..1f81eee407 100644
>> --- a/OvmfPkg/XenPlatformPei/MemDetect.c
>> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
>> @@ -96,6 +96,45 @@ Q35TsegMbytesInitialization (
>> mQ35TsegMbytes = ExtendedTsegMbytes;
>> }
>>
>> +STATIC
>> +UINT64
>> +GetHighestSystemMemoryAddress (
>> + BOOLEAN Below4gb
>> + )
>> +{
>> + EFI_E820_ENTRY64 *E820Map;
>> + UINT32 E820EntriesCount;
>> + EFI_E820_ENTRY64 *Entry;
>> + EFI_STATUS Status;
>> + UINT32 Loop;
>> + UINT64 HighestAddress;
>> + UINT64 EntryEnd;
>> +
>> + HighestAddress = 0;
>> +
>> + Status = XenGetE820Map (&E820Map, &E820EntriesCount);
>> + ASSERT_EFI_ERROR (Status);
>> +
>> + for (Loop = 0; Loop < E820EntriesCount; Loop++) {
>> + Entry = E820Map + Loop;
>> + EntryEnd = Entry->BaseAddr + Entry->Length;
>> +
>> + if (Entry->Type == EfiAcpiAddressRangeMemory &&
>> + EntryEnd > HighestAddress) {
>> +
>> + if (Below4gb && (EntryEnd <= BASE_4GB)) {
>> + HighestAddress = EntryEnd;
>> + } else if (!Below4gb && (EntryEnd >= BASE_4GB)) {
>> + HighestAddress = EntryEnd;
>> + }
>> + }
>> + }
>> +
>> + //
>> + // Round down the end address.
>> + //
>> + return HighestAddress & ~(UINT64)EFI_PAGE_MASK;
>> +}
>>
>> UINT32
>> GetSystemMemorySizeBelow4gb (
>> @@ -105,6 +144,19 @@ GetSystemMemorySizeBelow4gb (
>> UINT8 Cmos0x34;
>> UINT8 Cmos0x35;
>>
>> + //
>> + // In PVH case, there is no CMOS, we have to calculate the memory size
>> + // from parsing the E820
>> + //
>> + if (XenPvhDetected ()) {
>> + UINT64 HighestAddress;
>> +
>> + HighestAddress = GetHighestSystemMemoryAddress (TRUE);
>> + ASSERT (HighestAddress > 0 && HighestAddress <= BASE_4GB);
>> +
>> + return HighestAddress;
>> + }
>> +
>> //
>> // CMOS 0x34/0x35 specifies the system memory above 16 MB.
>> // * CMOS(0x35) is the high byte
>> @@ -129,6 +181,23 @@ GetSystemMemorySizeAbove4gb (
>> UINT32 Size;
>> UINTN CmosIndex;
>>
>> + //
>> + // In PVH case, there is no CMOS, we have to calculate the memory size
>> + // from parsing the E820
>> + //
>> + if (XenPvhDetected ()) {
>> + UINT64 HighestAddress;
>> +
>> + HighestAddress = GetHighestSystemMemoryAddress (FALSE);
>> + ASSERT (HighestAddress == 0 || HighestAddress >= BASE_4GB);
>> +
>> + if (HighestAddress >= BASE_4GB) {
>> + HighestAddress -= BASE_4GB;
>> + }
>> +
>> + return HighestAddress;
>> + }
>> +
>> //
>> // CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
>> // * CMOS(0x5d) is the most significant size byte
>> diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
>> index 6aaafc3ee9..2f42ca6ccd 100644
>> --- a/OvmfPkg/XenPlatformPei/Platform.c
>> +++ b/OvmfPkg/XenPlatformPei/Platform.c
>> @@ -102,6 +102,17 @@ AddReservedMemoryBaseSizeHob (
>> );
>> }
>>
>> +VOID
>> +AddReservedMemoryRangeHob (
>> + EFI_PHYSICAL_ADDRESS MemoryBase,
>> + EFI_PHYSICAL_ADDRESS MemoryLimit,
>> + BOOLEAN Cacheable
>> + )
>> +{
>> + AddReservedMemoryBaseSizeHob (MemoryBase,
>> + (UINT64)(MemoryLimit - MemoryBase), Cacheable);
>> +}
>> +
>> VOID
>> AddIoMemoryRangeHob (
>> EFI_PHYSICAL_ADDRESS MemoryBase,
>> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
>> index a21d657357..182e96cc5b 100644
>> --- a/OvmfPkg/XenPlatformPei/Xen.c
>> +++ b/OvmfPkg/XenPlatformPei/Xen.c
>> @@ -276,9 +276,12 @@ XenPublishRamRegions (
>> VOID
>> )
>> {
>> - EFI_E820_ENTRY64 *E820Map;
>> - UINT32 E820EntriesCount;
>> - EFI_STATUS Status;
>> + EFI_E820_ENTRY64 *E820Map;
>> + UINT32 E820EntriesCount;
>> + EFI_STATUS Status;
>> + EFI_E820_ENTRY64 *Entry;
>> + UINTN Index;
>> + EFI_PHYSICAL_ADDRESS LocalApic;
>>
>> DEBUG ((DEBUG_INFO, "Using memory map provided by Xen\n"));
>>
>> @@ -287,26 +290,47 @@ XenPublishRamRegions (
>> //
>> E820EntriesCount = 0;
>> Status = XenGetE820Map (&E820Map, &E820EntriesCount);
>> -
>> ASSERT_EFI_ERROR (Status);
>>
>> - if (E820EntriesCount > 0) {
>> - EFI_E820_ENTRY64 *Entry;
>> - UINT32 Loop;
>> -
>> - for (Loop = 0; Loop < E820EntriesCount; Loop++) {
>> - Entry = E820Map + Loop;
>> -
>> - //
>> - // Only care about RAM
>> - //
>> - if (Entry->Type != EfiAcpiAddressRangeMemory) {
>> - continue;
>> + LocalApic = PcdGet32(PcdCpuLocalApicBaseAddress);
>
> (2) missing space before "(" -- but, actually, please see below
>
>
>> + AddIoMemoryBaseSizeHob (LocalApic, SIZE_1MB);
>> +
>> + for (Index = 0; Index < E820EntriesCount; Index++) {
>> + UINT64 Base;
>> + UINT64 End;
>> +
>> + Entry = &E820Map[Index];
>> +
>> + //
>> + // Round up the start address, and round down the end address.
>> + //
>> + Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
>> + End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
>> +
>> + switch (Entry->Type) {
>> + case EfiAcpiAddressRangeMemory:
>> + AddMemoryRangeHob (Base, End);
>> + break;
>> + case EfiAcpiAddressRangeACPI:
>> + AddReservedMemoryRangeHob (Base, End, FALSE);
>> + break;
>> + case EfiAcpiAddressRangeReserved:
>> + if (Base < LocalApic && LocalApic < End) {
>> + //
>> + // hvmloader marks a range that overlaps with the local APIC memory
>> + // mapped region as reserved, but CpuDxe wants it as mapped IO. We
>> + // have already added it as mapped IO, so skip it here.
>> + //
>> + AddReservedMemoryRangeHob (Base, LocalApic, FALSE);
>> + if (End > (LocalApic + SIZE_1MB)) {
>> + AddReservedMemoryRangeHob (LocalApic + SIZE_1MB, End, FALSE);
>> + }
>> + } else {
>> + AddReservedMemoryRangeHob (Base, End, FALSE);
>> }
>
> (3) Not sure how general you want to be here, but I don't think this is
> fully general. How about:
>
> (3a) before the loop, drop "LocalApic", and add:
>
> UINT64 LapicBase;
> UINT64 LapicEnd;
>
> LapicBase = PcdGet32 (PcdCpuLocalApicBaseAddress);
> LapicEnd = LapicBase + SIZE_1MB;
>
> (3b) inside the loop body, near the top of the block, add:
>
> UINT64 ReservedBase;
> UINT64 ReservedEnd;
>
> (3c) under the EfiAcpiAddressRangeReserved case label:
>
> //
> // add LAPIC predecessor range, if any
> //
> ReservedBase = Base;
> ReservedEnd = MIN (End, LapicBase);
> if (ReservedBase < ReservedEnd) {
> AddReservedMemoryRangeHob (ReservedBase, ReservedEnd, FALSE);
> }
>
> //
> // add LAPIC successor range, if any
> //
> ReservedBase = MAX (Base, LapicEnd);
> ReservedEnd = End;
> if (ReservedBase < ReservedEnd) {
> AddReservedMemoryRangeHob (ReservedBase, ReservedEnd, FALSE);
> }
>
> This will cover all possible constellations between the [LapicBase,
> LapicEnd) and [Base, End) intervals.
>
> --*--
>
> Regarding the approach itself, I'll defer to Roger.
If you and Roger both think that the present patch is good enough
(because there is no issue in practice), I'm OK to ACK the patch -- I
can fix the typos (1) and (2) when pushing.
(What I propose under (3) could be posted as an incremental improvement,
if you agree with it. It could be ignored too, if you think the
suggested generality is speculative and would never be exercised in
practice.)
Thanks
Laszlo
>> -
>> - AddMemoryBaseSizeHob (Entry->BaseAddr, Entry->Length);
>> -
>> - MtrrSetMemoryAttribute (Entry->BaseAddr, Entry->Length, CacheWriteBack);
>> + break;
>> + default:
>> + break;
>> }
>> }
>> }
>> @@ -326,12 +350,6 @@ InitializeXen (
>> {
>> RETURN_STATUS PcdStatus;
>>
>> - //
>> - // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
>> - // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
>> - //
>> - AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000, FALSE);
>> -
>> PcdStatus = PcdSetBoolS (PcdPciDisableBusEnumeration, TRUE);
>> ASSERT_RETURN_ERROR (PcdStatus);
>>
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [PATCH v4 23/35] OvmfPkg/XenPlatformPei: Rework memory detection
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 23/35] OvmfPkg/XenPlatformPei: Rework memory detection Anthony PERARD
2019-07-30 11:45 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
@ 2019-08-07 15:34 ` Roger Pau Monné
2019-08-08 11:13 ` Anthony PERARD
1 sibling, 1 reply; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 15:34 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall,
Andrew Cooper, xen-devel, Laszlo Ersek
On Mon, Jul 29, 2019 at 04:39:32PM +0100, Anthony PERARD wrote:
> When running as a Xen PVH guest, there is no CMOS to read the memory
> size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
> work without CMOS by reading the e820 table.
>
> Rework XenPublishRamRegions to also care for the reserved and ACPI
> entry in the e820 table. The region that was added by InitializeXen()
> isn't needed as that same entry is in the e820 table provided by
> hvmloader.
>
> MTRR settings aren't modified anymore, on HVM it's already done by
> hvmloader, on PVH it is supposed to have sane default. MTRR will need
> to be done properly but keeping what's already been done by programmes
^ firmware
> that has runned before OVMF will do for now.
^ ran
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index a21d657357..182e96cc5b 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -276,9 +276,12 @@ XenPublishRamRegions (
> VOID
> )
> {
> - EFI_E820_ENTRY64 *E820Map;
> - UINT32 E820EntriesCount;
> - EFI_STATUS Status;
> + EFI_E820_ENTRY64 *E820Map;
> + UINT32 E820EntriesCount;
> + EFI_STATUS Status;
> + EFI_E820_ENTRY64 *Entry;
> + UINTN Index;
> + EFI_PHYSICAL_ADDRESS LocalApic;
>
> DEBUG ((DEBUG_INFO, "Using memory map provided by Xen\n"));
>
> @@ -287,26 +290,47 @@ XenPublishRamRegions (
> //
> E820EntriesCount = 0;
> Status = XenGetE820Map (&E820Map, &E820EntriesCount);
> -
> ASSERT_EFI_ERROR (Status);
>
> - if (E820EntriesCount > 0) {
> - EFI_E820_ENTRY64 *Entry;
> - UINT32 Loop;
> -
> - for (Loop = 0; Loop < E820EntriesCount; Loop++) {
> - Entry = E820Map + Loop;
> -
> - //
> - // Only care about RAM
> - //
> - if (Entry->Type != EfiAcpiAddressRangeMemory) {
> - continue;
> + LocalApic = PcdGet32(PcdCpuLocalApicBaseAddress);
> + AddIoMemoryBaseSizeHob (LocalApic, SIZE_1MB);
> +
> + for (Index = 0; Index < E820EntriesCount; Index++) {
> + UINT64 Base;
> + UINT64 End;
> +
> + Entry = &E820Map[Index];
> +
> + //
> + // Round up the start address, and round down the end address.
> + //
> + Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
> + End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
> +
> + switch (Entry->Type) {
> + case EfiAcpiAddressRangeMemory:
> + AddMemoryRangeHob (Base, End);
> + break;
> + case EfiAcpiAddressRangeACPI:
> + AddReservedMemoryRangeHob (Base, End, FALSE);
> + break;
> + case EfiAcpiAddressRangeReserved:
> + if (Base < LocalApic && LocalApic < End) {
Don't you also need to check for equality? In case such region starts
at Base == LocalApic?
I guess it doesn't matter that much since this is to workaround a
specific issue with hvmloader, but I would like to see this sorted out
in hvmloader so that there's no clash anymore.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [Xen-devel] [PATCH v4 23/35] OvmfPkg/XenPlatformPei: Rework memory detection
2019-08-07 15:34 ` [Xen-devel] " Roger Pau Monné
@ 2019-08-08 11:13 ` Anthony PERARD
0 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-08-08 11:13 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall,
Andrew Cooper, xen-devel, Laszlo Ersek
On Wed, Aug 07, 2019 at 05:34:32PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:32PM +0100, Anthony PERARD wrote:
> > When running as a Xen PVH guest, there is no CMOS to read the memory
> > size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
> > work without CMOS by reading the e820 table.
> >
> > Rework XenPublishRamRegions to also care for the reserved and ACPI
> > entry in the e820 table. The region that was added by InitializeXen()
> > isn't needed as that same entry is in the e820 table provided by
> > hvmloader.
> >
> > MTRR settings aren't modified anymore, on HVM it's already done by
> > hvmloader, on PVH it is supposed to have sane default. MTRR will need
> > to be done properly but keeping what's already been done by programmes
> ^ firmware
I've used programmes instead of firmware because in case of PVH, OVMF is
the first firmware to run, libxl (and what ever it called) is what
causes an MTRR to be setup, no firmware are involved in that.
> > + //
> > + // Round up the start address, and round down the end address.
> > + //
> > + Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
> > + End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
> > +
> > + switch (Entry->Type) {
> > + case EfiAcpiAddressRangeMemory:
> > + AddMemoryRangeHob (Base, End);
> > + break;
> > + case EfiAcpiAddressRangeACPI:
> > + AddReservedMemoryRangeHob (Base, End, FALSE);
> > + break;
> > + case EfiAcpiAddressRangeReserved:
> > + if (Base < LocalApic && LocalApic < End) {
>
> Don't you also need to check for equality? In case such region starts
> at Base == LocalApic?
>
> I guess it doesn't matter that much since this is to workaround a
> specific issue with hvmloader, but I would like to see this sorted out
> in hvmloader so that there's no clash anymore.
Indeed, it doesn't matter to much, so I've been lazy. But Laszlo have
pointed that out as well, so there were going to be a patch to make the
workaround better. But I feel like I'm going to need to repost the
series, so I'm probably going to fix that as well.
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 24/35] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (22 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 23/35] OvmfPkg/XenPlatformPei: Rework memory detection Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 25/35] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH Anthony PERARD
` (12 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Linux panic if the VGA region isn't reserved.
When Linux is booted on EFI system, it expects the memory at 0xa0000 to
_not_ be conventional memory. Otherwise a variable isn't initialised
properly and Linux panic when a virtual console/terminal is asked to be
created.
See for more detail:
https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02139.html
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- fix commit message
OvmfPkg/XenPlatformPei/Xen.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 182e96cc5b..c3eabe7fa4 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -292,6 +292,12 @@ XenPublishRamRegions (
Status = XenGetE820Map (&E820Map, &E820EntriesCount);
ASSERT_EFI_ERROR (Status);
+ AddMemoryBaseSizeHob (0, 0xA0000);
+ //
+ // Video memory + Legacy BIOS region, to allow Linux to boot.
+ //
+ AddReservedMemoryBaseSizeHob (0xA0000, BASE_1MB - 0xA0000, TRUE);
+
LocalApic = PcdGet32(PcdCpuLocalApicBaseAddress);
AddIoMemoryBaseSizeHob (LocalApic, SIZE_1MB);
@@ -307,6 +313,16 @@ XenPublishRamRegions (
Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
+ //
+ // Ignore the first 1MB, this is handled before the loop.
+ //
+ if (Base < BASE_1MB) {
+ Base = BASE_1MB;
+ }
+ if (Base >= End) {
+ continue;
+ }
+
switch (Entry->Type) {
case EfiAcpiAddressRangeMemory:
AddMemoryRangeHob (Base, End);
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 25/35] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (23 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 24/35] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 26/35] OvmfPkg/XenPlatformLib: Cache result for XenDetected Anthony PERARD
` (11 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
When the device ID of the host bridge is unknown, check if we are
running as a PVH guest as there is no PCI bus in that case.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- Remove use of XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID, and simply don't set
PcdOvmfHostBridgePciDevId.
v2:
- Use new XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID macro
OvmfPkg/XenPlatformPei/Platform.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/Platform.c b/OvmfPkg/XenPlatformPei/Platform.c
index 2f42ca6ccd..717fd0ab1a 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -283,6 +283,12 @@ MiscInitialization (
AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
break;
default:
+ if (XenPvhDetected ()) {
+ //
+ // There is no PCI bus in this case
+ //
+ return;
+ }
DEBUG ((DEBUG_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
__FUNCTION__, mHostBridgeDevId));
ASSERT (FALSE);
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 26/35] OvmfPkg/XenPlatformLib: Cache result for XenDetected
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (24 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 25/35] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 27/35] OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLib Anthony PERARD
` (10 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
We are going to replace XenDetected() implementation in
PlatformBootManagerLib by the one in XenPlatformLib.
PlatformBootManagerLib's implementation does cache the result of
GetFirstGuidHob(), so we do something similar in XenPlatformLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- fix coding style
v3:
- new patch
.../Library/XenPlatformLib/XenPlatformLib.c | 20 +++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
index 974a0e73f1..8f20ae2d45 100644
--- a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
@@ -25,14 +25,26 @@ XenGetInfoHOB (
VOID
)
{
- EFI_HOB_GUID_TYPE *GuidHob;
+ EFI_HOB_GUID_TYPE *GuidHob;
+ STATIC BOOLEAN Cached = FALSE;
+ STATIC EFI_XEN_INFO *XenInfo;
+
+ //
+ // Return the cached result for the benefit of XenDetected that can be
+ // called many times.
+ //
+ if (Cached) {
+ return XenInfo;
+ }
GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
if (GuidHob == NULL) {
- return NULL;
+ XenInfo = NULL;
+ } else {
+ XenInfo = (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
}
-
- return (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
+ Cached = TRUE;
+ return XenInfo;
}
/**
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 27/35] OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLib
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (25 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 26/35] OvmfPkg/XenPlatformLib: Cache result for XenDetected Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 28/35] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH Anthony PERARD
` (9 subsequent siblings)
36 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Replace the XenDetected() implementation by the one from
XenPlatformLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- removed gEfiXenInfoGuid from Guids list and the associated include of
Guid/XenInfo.h
v3:
- new patch
.../PlatformBootManagerLib.inf | 2 +-
.../PlatformBootManagerLib/BdsPlatform.c | 34 +------------------
2 files changed, 2 insertions(+), 34 deletions(-)
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 060a3ab4c5..04d614cd49 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -54,6 +54,7 @@ [LibraryClasses]
UefiLib
PlatformBmPrintScLib
Tcg2PhysicalPresenceLib
+ XenPlatformLib
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent
@@ -73,7 +74,6 @@ [Protocols]
gEfiFirmwareVolume2ProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
[Guids]
- gEfiXenInfoGuid
gEfiEndOfDxeEventGroupGuid
gRootBridgesConnectedEventGroupGuid
gUefiShellFileGuid
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 797731a41c..d5d5d20fd8 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -7,11 +7,11 @@
**/
#include "BdsPlatform.h"
-#include <Guid/XenInfo.h>
#include <Guid/RootBridgesConnectedEventGroup.h>
#include <Protocol/FirmwareVolume2.h>
#include <Library/PlatformBmPrintScLib.h>
#include <Library/Tcg2PhysicalPresenceLib.h>
+#include <Library/XenPlatformLib.h>
//
@@ -1225,38 +1225,6 @@ PciAcpiInitialization (
IoOr16 ((PciRead32 (Pmba) & ~BIT0) + 4, BIT0);
}
-/**
- This function detects if OVMF is running on Xen.
-
-**/
-STATIC
-BOOLEAN
-XenDetected (
- VOID
- )
-{
- EFI_HOB_GUID_TYPE *GuidHob;
- STATIC INTN FoundHob = -1;
-
- if (FoundHob == 0) {
- return FALSE;
- } else if (FoundHob == 1) {
- return TRUE;
- }
-
- //
- // See if a XenInfo HOB is available
- //
- GuidHob = GetFirstGuidHob (&gEfiXenInfoGuid);
- if (GuidHob == NULL) {
- FoundHob = 0;
- return FALSE;
- }
-
- FoundHob = 1;
- return TRUE;
-}
-
EFI_STATUS
EFIAPI
ConnectRecursivelyIfPciMassStorage (
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* [Xen-devel] [PATCH v4 28/35] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (26 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 27/35] OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLib Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-08-07 15:50 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency Anthony PERARD
` (8 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
When running in a Xen PVH guest, there's nothing to do in
PciAcpiInitialization() because there isn't any PCI bus. When the Host
Bridge DID isn't recognised, simply continue. (The value of
PcdOvmfHostBridgePciDevId would be 0 because it isn't set.)
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- Instead of checking for a false value,
XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID, simply check if we are running xen
when the HostBridge device ID isn't recognised.
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index d5d5d20fd8..1eba304f09 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1208,6 +1208,12 @@ PciAcpiInitialization (
PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
break;
default:
+ if (XenDetected ()) {
+ //
+ // There is no PCI bus in this case.
+ //
+ return;
+ }
DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
__FUNCTION__, mHostBridgeDevId));
ASSERT (FALSE);
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 28/35] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 28/35] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH Anthony PERARD
@ 2019-08-07 15:50 ` Roger Pau Monné
0 siblings, 0 replies; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 15:50 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Laszlo Ersek, Jordan Justen
On Mon, Jul 29, 2019 at 04:39:37PM +0100, Anthony PERARD wrote:
> When running in a Xen PVH guest, there's nothing to do in
> PciAcpiInitialization() because there isn't any PCI bus. When the Host
> Bridge DID isn't recognised, simply continue. (The value of
> PcdOvmfHostBridgePciDevId would be 0 because it isn't set.)
I guess we will need to figure out how to make OVMF happy when
passthrough support is added to PVH. Having to fake a bridge is quite
cumbersome, but I assume OVMF only pokes at some specific bridge
registers which we might be able to emulate without much fuss.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (27 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 28/35] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-08-07 15:54 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 30/35] OvmfPkg/OvmfXen: Introduce XenTimerDxe Anthony PERARD
` (7 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
implementation. It will also be used by XenTimerDxe. Override
PcdFSBClock to match Xen vLAPIC timer frequency.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- expand commit message body to be standalone
OvmfPkg/OvmfXen.dsc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 22970eda5d..477d8c76a1 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -439,6 +439,9 @@ [PcdsFixedAtBuild]
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
+ ## Xen vlapic's frequence is 100 MHz
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock|100000000
+
################################################################################
#
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency Anthony PERARD
@ 2019-08-07 15:54 ` Roger Pau Monné
2019-08-08 13:28 ` Anthony PERARD
0 siblings, 1 reply; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 15:54 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Laszlo Ersek, Jordan Justen
On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote:
> PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
> implementation. It will also be used by XenTimerDxe. Override
> PcdFSBClock to match Xen vLAPIC timer frequency.
I'm kind of surprised that his is not automatically detected?
Is it a bug in Xen or just always hardcoded on OVMF?
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
2019-08-07 15:54 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
@ 2019-08-08 13:28 ` Anthony PERARD
2019-08-08 13:44 ` Roger Pau Monné
0 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-08-08 13:28 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote:
> > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
> > implementation. It will also be used by XenTimerDxe. Override
> > PcdFSBClock to match Xen vLAPIC timer frequency.
>
> I'm kind of surprised that his is not automatically detected?
>
> Is it a bug in Xen or just always hardcoded on OVMF?
It's hardcoded. Why would you need auto detection when you always run on
the same machine ;-).
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
2019-08-08 13:28 ` Anthony PERARD
@ 2019-08-08 13:44 ` Roger Pau Monné
2019-08-08 14:26 ` Anthony PERARD
2019-08-08 20:27 ` Laszlo Ersek
0 siblings, 2 replies; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-08 13:44 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote:
> > > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
> > > implementation. It will also be used by XenTimerDxe. Override
> > > PcdFSBClock to match Xen vLAPIC timer frequency.
> >
> > I'm kind of surprised that his is not automatically detected?
> >
> > Is it a bug in Xen or just always hardcoded on OVMF?
>
> It's hardcoded. Why would you need auto detection when you always run on
> the same machine ;-).
I don't think that's part of the HVM/PVH ABI in any way, and if you
hardcode it in OVMF it would prevent Xen from changing the frequency
in the future if such necessity arises. We should try to avoid painting
ourselves into a corner when possible.
Doesn't OVMF have a way to get this from the hardware itself?
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
2019-08-08 13:44 ` Roger Pau Monné
@ 2019-08-08 14:26 ` Anthony PERARD
2019-08-08 15:18 ` Roger Pau Monné
2019-08-08 20:27 ` Laszlo Ersek
1 sibling, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-08-08 14:26 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Thu, Aug 08, 2019 at 03:44:23PM +0200, Roger Pau Monné wrote:
> On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote:
> > On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote:
> > > On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote:
> > > > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
> > > > implementation. It will also be used by XenTimerDxe. Override
> > > > PcdFSBClock to match Xen vLAPIC timer frequency.
> > >
> > > I'm kind of surprised that his is not automatically detected?
> > >
> > > Is it a bug in Xen or just always hardcoded on OVMF?
> >
> > It's hardcoded. Why would you need auto detection when you always run on
> > the same machine ;-).
>
> I don't think that's part of the HVM/PVH ABI in any way, and if you
> hardcode it in OVMF it would prevent Xen from changing the frequency
> in the future if such necessity arises. We should try to avoid painting
> ourselves into a corner when possible.
>
> Doesn't OVMF have a way to get this from the hardware itself?
So EDKII doesn't have that capability, FSBClock is a build time value
and can't be changed at run time. But OVMF (on KVM or HVM) doesn't use
that value at all, it uses the ACPI timer instead.
We could try to find a better way to get time in OvmfXen without
hardcoding FSBClock, but maybe in a follow-up.
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
2019-08-08 14:26 ` Anthony PERARD
@ 2019-08-08 15:18 ` Roger Pau Monné
2019-08-12 14:45 ` Anthony PERARD
0 siblings, 1 reply; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-08 15:18 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Thu, Aug 08, 2019 at 03:26:41PM +0100, Anthony PERARD wrote:
> On Thu, Aug 08, 2019 at 03:44:23PM +0200, Roger Pau Monné wrote:
> > On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote:
> > > On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote:
> > > > On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote:
> > > > > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
> > > > > implementation. It will also be used by XenTimerDxe. Override
> > > > > PcdFSBClock to match Xen vLAPIC timer frequency.
> > > >
> > > > I'm kind of surprised that his is not automatically detected?
> > > >
> > > > Is it a bug in Xen or just always hardcoded on OVMF?
> > >
> > > It's hardcoded. Why would you need auto detection when you always run on
> > > the same machine ;-).
> >
> > I don't think that's part of the HVM/PVH ABI in any way, and if you
> > hardcode it in OVMF it would prevent Xen from changing the frequency
> > in the future if such necessity arises. We should try to avoid painting
> > ourselves into a corner when possible.
> >
> > Doesn't OVMF have a way to get this from the hardware itself?
>
> So EDKII doesn't have that capability, FSBClock is a build time value
> and can't be changed at run time. But OVMF (on KVM or HVM) doesn't use
> that value at all, it uses the ACPI timer instead.
But after your series both PVH and HVM will use the lapic timer
instead of the ACPI timer, and thus rely on the value of FSBClock?
> We could try to find a better way to get time in OvmfXen without
> hardcoding FSBClock, but maybe in a follow-up.
Yes please. As said above lapic frequency is not part of the ABI, so
if we need to use it like that APIC_BUS_CYCLE_NS (currently in
vlapic.h) would have to be moved to a public header.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
2019-08-08 15:18 ` Roger Pau Monné
@ 2019-08-12 14:45 ` Anthony PERARD
0 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-08-12 14:45 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Thu, Aug 08, 2019 at 05:18:15PM +0200, Roger Pau Monné wrote:
> On Thu, Aug 08, 2019 at 03:26:41PM +0100, Anthony PERARD wrote:
> > So EDKII doesn't have that capability, FSBClock is a build time value
> > and can't be changed at run time. But OVMF (on KVM or HVM) doesn't use
> > that value at all, it uses the ACPI timer instead.
>
> But after your series both PVH and HVM will use the lapic timer
> instead of the ACPI timer, and thus rely on the value of FSBClock?
Short answer, Yes.
Longuer answer, after the series is applied, there will be a new
platform, "OvmfXen" which will be for both Xen PVH and Xen HVM, but the
OVMF that we know (OvmfPkgX64 that xen.git builds) will still be
capable of running on Xen HVM for a short while and will still use the
ACPI timer.
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
2019-08-08 13:44 ` Roger Pau Monné
2019-08-08 14:26 ` Anthony PERARD
@ 2019-08-08 20:27 ` Laszlo Ersek
1 sibling, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-08-08 20:27 UTC (permalink / raw)
To: Roger Pau Monné, Anthony PERARD
Cc: xen-devel, devel, Ard Biesheuvel, Julien Grall, Jordan Justen
On 08/08/19 15:44, Roger Pau Monné wrote:
> On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote:
>> On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote:
>>> On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote:
>>>> PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
>>>> implementation. It will also be used by XenTimerDxe. Override
>>>> PcdFSBClock to match Xen vLAPIC timer frequency.
>>>
>>> I'm kind of surprised that his is not automatically detected?
>>>
>>> Is it a bug in Xen or just always hardcoded on OVMF?
>>
>> It's hardcoded. Why would you need auto detection when you always run on
>> the same machine ;-).
>
> I don't think that's part of the HVM/PVH ABI in any way, and if you
> hardcode it in OVMF it would prevent Xen from changing the frequency
> in the future if such necessity arises. We should try to avoid painting
> ourselves into a corner when possible.
>
> Doesn't OVMF have a way to get this from the hardware itself?
It might be possible to change the PCDs access method in the DSC file to
"dynamic", and then set it dynamically in XenPlatformPei. That should
work fine if only the DXE phase relies on the PCD. However, if PEIMs
(other than XenPlatformPei) consume the PCD too, then the ordering
(between set/get) might not be trivial to ensure. This kind of problem
sometimes requries separate library instances for SEC/PEI/DXE.
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 30/35] OvmfPkg/OvmfXen: Introduce XenTimerDxe
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (28 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 12:30 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn Anthony PERARD
` (6 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
"OvmfPkg/8254TimerDxe" is replaced with a Xen-specific
EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
8259InterruptControllerDxe as it is not used anymore.
This Timer uses the local APIC timer as time source as it can work on
both a Xen PVH guest and an HVM one.
Based on the "OvmfPkg/8254TimerDxe" implementation.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- fix the commit message to reflect the fact that the original code as
moved.
- Update Maintainers.txt
v3:
- rebased, SPDX, copyright
v2:
- Use InitializeApicTimer instead of WriteLocalApicReg
- rework comments (remove many that don't apply)
- remove unused includes, and libs
- have a macro to the timervector.
- cleanup, copyright
- rework calculation of TimerCount, value to be use by the APIC timer
- check for overflow of TimerPeriod, with the apic timer, the period can
be up to about 42s on Xen (or even higher by changing the DivideValue).
OvmfPkg/OvmfXen.dsc | 3 +-
OvmfPkg/OvmfXen.fdf | 3 +-
OvmfPkg/XenTimerDxe/XenTimerDxe.inf | 42 ++++
OvmfPkg/XenTimerDxe/XenTimerDxe.h | 177 ++++++++++++++
OvmfPkg/XenTimerDxe/XenTimerDxe.c | 355 ++++++++++++++++++++++++++++
Maintainers.txt | 1 +
6 files changed, 577 insertions(+), 4 deletions(-)
create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.inf
create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.h
create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.c
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 477d8c76a1..54ac910d8e 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -547,10 +547,9 @@ [Components]
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
- OvmfPkg/8259InterruptControllerDxe/8259.inf
+ OvmfPkg/XenTimerDxe/XenTimerDxe.inf
UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
UefiCpuPkg/CpuDxe/CpuDxe.inf
- OvmfPkg/8254TimerDxe/8254Timer.inf
OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 49997fee9b..fa0830a324 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -298,10 +298,9 @@ [FV.DXEFV]
INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-INF OvmfPkg/8259InterruptControllerDxe/8259.inf
+INF OvmfPkg/XenTimerDxe/XenTimerDxe.inf
INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
INF UefiCpuPkg/CpuDxe/CpuDxe.inf
-INF OvmfPkg/8254TimerDxe/8254Timer.inf
INF OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
INF OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
diff --git a/OvmfPkg/XenTimerDxe/XenTimerDxe.inf b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
new file mode 100644
index 0000000000..add1d01bbf
--- /dev/null
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
@@ -0,0 +1,42 @@
+## @file
+# Local APIC timer driver that provides Timer Arch protocol.
+#
+# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019, Citrix Systems, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION = 0x00010005
+ BASE_NAME = XenTimerDxe
+ FILE_GUID = 52fe8196-f9de-4d07-b22f-51f77a0e7c41
+ MODULE_TYPE = DXE_DRIVER
+ VERSION_STRING = 1.0
+
+ ENTRY_POINT = TimerDriverInitialize
+
+[Packages]
+ MdePkg/MdePkg.dec
+ UefiCpuPkg/UefiCpuPkg.dec
+ OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+ UefiBootServicesTableLib
+ BaseLib
+ DebugLib
+ UefiDriverEntryPoint
+ LocalApicLib
+
+[Sources]
+ XenTimerDxe.h
+ XenTimerDxe.c
+
+[Protocols]
+ gEfiCpuArchProtocolGuid ## CONSUMES
+ gEfiTimerArchProtocolGuid ## PRODUCES
+[Pcd]
+ gEfiMdePkgTokenSpaceGuid.PcdFSBClock ## CONSUMES
+[Depex]
+ gEfiCpuArchProtocolGuid
diff --git a/OvmfPkg/XenTimerDxe/XenTimerDxe.h b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
new file mode 100644
index 0000000000..e0a3d95fd0
--- /dev/null
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
@@ -0,0 +1,177 @@
+/** @file
+ Private data structures
+
+Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2019, Citrix Systems, Inc.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _TIMER_H_
+#define _TIMER_H_
+
+#include <PiDxe.h>
+
+#include <Protocol/Cpu.h>
+#include <Protocol/Timer.h>
+
+#include <Register/LocalApic.h>
+
+#include <Library/UefiBootServicesTableLib.h>
+#include <Library/BaseLib.h>
+#include <Library/DebugLib.h>
+#include <Library/LocalApicLib.h>
+#include <Library/PcdLib.h>
+
+// The default timer tick duration is set to 10 ms = 100000 100 ns units
+//
+#define DEFAULT_TIMER_TICK_DURATION 100000
+
+//
+// The Timer Vector use for interrupt
+//
+#define LOCAL_APIC_TIMER_VECTOR 32
+
+//
+// Function Prototypes
+//
+/**
+ Initialize the Timer Architectural Protocol driver
+
+ @param ImageHandle ImageHandle of the loaded driver
+ @param SystemTable Pointer to the System Table
+
+ @retval EFI_SUCCESS Timer Architectural Protocol created
+ @retval EFI_OUT_OF_RESOURCES Not enough resources available to initialize driver.
+ @retval EFI_DEVICE_ERROR A device error occurred attempting to initialize the driver.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverInitialize (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+;
+
+/**
+
+ This function adjusts the period of timer interrupts to the value specified
+ by TimerPeriod. If the timer period is updated, then the selected timer
+ period is stored in EFI_TIMER.TimerPeriod, and EFI_SUCCESS is returned. If
+ the timer hardware is not programmable, then EFI_UNSUPPORTED is returned.
+ If an error occurs while attempting to update the timer period, then the
+ timer hardware will be put back in its state prior to this call, and
+ EFI_DEVICE_ERROR is returned. If TimerPeriod is 0, then the timer interrupt
+ is disabled. This is not the same as disabling the CPU's interrupts.
+ Instead, it must either turn off the timer hardware, or it must adjust the
+ interrupt controller so that a CPU interrupt is not generated when the timer
+ interrupt fires.
+
+
+ @param This The EFI_TIMER_ARCH_PROTOCOL instance.
+ @param NotifyFunction The rate to program the timer interrupt in 100 nS units. If
+ the timer hardware is not programmable, then EFI_UNSUPPORTED is
+ returned. If the timer is programmable, then the timer period
+ will be rounded up to the nearest timer period that is supported
+ by the timer hardware. If TimerPeriod is set to 0, then the
+ timer interrupts will be disabled.
+
+ @retval EFI_SUCCESS The timer period was changed.
+ @retval EFI_UNSUPPORTED The platform cannot change the period of the timer interrupt.
+ @retval EFI_DEVICE_ERROR The timer period could not be changed due to a device error.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverRegisterHandler (
+ IN EFI_TIMER_ARCH_PROTOCOL *This,
+ IN EFI_TIMER_NOTIFY NotifyFunction
+ )
+;
+
+/**
+
+ This function adjusts the period of timer interrupts to the value specified
+ by TimerPeriod. If the timer period is updated, then the selected timer
+ period is stored in EFI_TIMER.TimerPeriod, and EFI_SUCCESS is returned. If
+ the timer hardware is not programmable, then EFI_UNSUPPORTED is returned.
+ If an error occurs while attempting to update the timer period, then the
+ timer hardware will be put back in its state prior to this call, and
+ EFI_DEVICE_ERROR is returned. If TimerPeriod is 0, then the timer interrupt
+ is disabled. This is not the same as disabling the CPU's interrupts.
+ Instead, it must either turn off the timer hardware, or it must adjust the
+ interrupt controller so that a CPU interrupt is not generated when the timer
+ interrupt fires.
+
+
+ @param This The EFI_TIMER_ARCH_PROTOCOL instance.
+ @param TimerPeriod The rate to program the timer interrupt in 100 nS units. If
+ the timer hardware is not programmable, then EFI_UNSUPPORTED is
+ returned. If the timer is programmable, then the timer period
+ will be rounded up to the nearest timer period that is supported
+ by the timer hardware. If TimerPeriod is set to 0, then the
+ timer interrupts will be disabled.
+
+ @retval EFI_SUCCESS The timer period was changed.
+ @retval EFI_UNSUPPORTED The platform cannot change the period of the timer interrupt.
+ @retval EFI_DEVICE_ERROR The timer period could not be changed due to a device error.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverSetTimerPeriod (
+ IN EFI_TIMER_ARCH_PROTOCOL *This,
+ IN UINT64 TimerPeriod
+ )
+;
+
+/**
+
+ This function retrieves the period of timer interrupts in 100 ns units,
+ returns that value in TimerPeriod, and returns EFI_SUCCESS. If TimerPeriod
+ is NULL, then EFI_INVALID_PARAMETER is returned. If a TimerPeriod of 0 is
+ returned, then the timer is currently disabled.
+
+
+ @param This The EFI_TIMER_ARCH_PROTOCOL instance.
+ @param TimerPeriod A pointer to the timer period to retrieve in 100 ns units. If
+ 0 is returned, then the timer is currently disabled.
+
+ @retval EFI_SUCCESS The timer period was returned in TimerPeriod.
+ @retval EFI_INVALID_PARAMETER TimerPeriod is NULL.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverGetTimerPeriod (
+ IN EFI_TIMER_ARCH_PROTOCOL *This,
+ OUT UINT64 *TimerPeriod
+ )
+;
+
+/**
+
+ This function generates a soft timer interrupt. If the platform does not support soft
+ timer interrupts, then EFI_UNSUPPORTED is returned. Otherwise, EFI_SUCCESS is returned.
+ If a handler has been registered through the EFI_TIMER_ARCH_PROTOCOL.RegisterHandler()
+ service, then a soft timer interrupt will be generated. If the timer interrupt is
+ enabled when this service is called, then the registered handler will be invoked. The
+ registered handler should not be able to distinguish a hardware-generated timer
+ interrupt from a software-generated timer interrupt.
+
+
+ @param This The EFI_TIMER_ARCH_PROTOCOL instance.
+
+ @retval EFI_SUCCESS The soft timer interrupt was generated.
+ @retval EFI_UNSUPPORTED The platform does not support the generation of soft timer interrupts.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverGenerateSoftInterrupt (
+ IN EFI_TIMER_ARCH_PROTOCOL *This
+ )
+;
+
+#endif
diff --git a/OvmfPkg/XenTimerDxe/XenTimerDxe.c b/OvmfPkg/XenTimerDxe/XenTimerDxe.c
new file mode 100644
index 0000000000..9f9e04766c
--- /dev/null
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.c
@@ -0,0 +1,355 @@
+/** @file
+ Timer Architectural Protocol as defined in the DXE CIS
+
+Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2019, Citrix Systems, Inc.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "XenTimerDxe.h"
+
+//
+// The handle onto which the Timer Architectural Protocol will be installed
+//
+EFI_HANDLE mTimerHandle = NULL;
+
+//
+// The Timer Architectural Protocol that this driver produces
+//
+EFI_TIMER_ARCH_PROTOCOL mTimer = {
+ TimerDriverRegisterHandler,
+ TimerDriverSetTimerPeriod,
+ TimerDriverGetTimerPeriod,
+ TimerDriverGenerateSoftInterrupt
+};
+
+//
+// Pointer to the CPU Architectural Protocol instance
+//
+EFI_CPU_ARCH_PROTOCOL *mCpu;
+
+//
+// The notification function to call on every timer interrupt.
+// A bug in the compiler prevents us from initializing this here.
+//
+EFI_TIMER_NOTIFY mTimerNotifyFunction;
+
+//
+// The current period of the timer interrupt
+//
+volatile UINT64 mTimerPeriod = 0;
+
+//
+// Worker Functions
+//
+/**
+ Interrupt Handler.
+
+ @param InterruptType The type of interrupt that occurred
+ @param SystemContext A pointer to the system context when the interrupt occurred
+**/
+VOID
+EFIAPI
+TimerInterruptHandler (
+ IN EFI_EXCEPTION_TYPE InterruptType,
+ IN EFI_SYSTEM_CONTEXT SystemContext
+ )
+{
+ EFI_TPL OriginalTPL;
+
+ OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
+
+ SendApicEoi();
+
+ if (mTimerNotifyFunction != NULL) {
+ //
+ // @bug : This does not handle missed timer interrupts
+ //
+ mTimerNotifyFunction (mTimerPeriod);
+ }
+
+ gBS->RestoreTPL (OriginalTPL);
+}
+
+/**
+
+ This function registers the handler NotifyFunction so it is called every time
+ the timer interrupt fires. It also passes the amount of time since the last
+ handler call to the NotifyFunction. If NotifyFunction is NULL, then the
+ handler is unregistered. If the handler is registered, then EFI_SUCCESS is
+ returned. If the CPU does not support registering a timer interrupt handler,
+ then EFI_UNSUPPORTED is returned. If an attempt is made to register a handler
+ when a handler is already registered, then EFI_ALREADY_STARTED is returned.
+ If an attempt is made to unregister a handler when a handler is not registered,
+ then EFI_INVALID_PARAMETER is returned. If an error occurs attempting to
+ register the NotifyFunction with the timer interrupt, then EFI_DEVICE_ERROR
+ is returned.
+
+
+ @param This The EFI_TIMER_ARCH_PROTOCOL instance.
+ @param NotifyFunction The function to call when a timer interrupt fires. This
+ function executes at TPL_HIGH_LEVEL. The DXE Core will
+ register a handler for the timer interrupt, so it can know
+ how much time has passed. This information is used to
+ signal timer based events. NULL will unregister the handler.
+
+ @retval EFI_SUCCESS The timer handler was registered.
+ @retval EFI_UNSUPPORTED The platform does not support timer interrupts.
+ @retval EFI_ALREADY_STARTED NotifyFunction is not NULL, and a handler is already
+ registered.
+ @retval EFI_INVALID_PARAMETER NotifyFunction is NULL, and a handler was not
+ previously registered.
+ @retval EFI_DEVICE_ERROR The timer handler could not be registered.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverRegisterHandler (
+ IN EFI_TIMER_ARCH_PROTOCOL *This,
+ IN EFI_TIMER_NOTIFY NotifyFunction
+ )
+{
+ //
+ // Check for invalid parameters
+ //
+ if (NotifyFunction == NULL && mTimerNotifyFunction == NULL) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ if (NotifyFunction != NULL && mTimerNotifyFunction != NULL) {
+ return EFI_ALREADY_STARTED;
+ }
+
+ mTimerNotifyFunction = NotifyFunction;
+
+ return EFI_SUCCESS;
+}
+
+/**
+
+ This function adjusts the period of timer interrupts to the value specified
+ by TimerPeriod. If the timer period is updated, then the selected timer
+ period is stored in EFI_TIMER.TimerPeriod, and EFI_SUCCESS is returned. If
+ the timer hardware is not programmable, then EFI_UNSUPPORTED is returned.
+ If an error occurs while attempting to update the timer period, then the
+ timer hardware will be put back in its state prior to this call, and
+ EFI_DEVICE_ERROR is returned. If TimerPeriod is 0, then the timer interrupt
+ is disabled. This is not the same as disabling the CPU's interrupts.
+ Instead, it must either turn off the timer hardware, or it must adjust the
+ interrupt controller so that a CPU interrupt is not generated when the timer
+ interrupt fires.
+
+
+ @param This The EFI_TIMER_ARCH_PROTOCOL instance.
+ @param TimerPeriod The rate to program the timer interrupt in 100 nS units. If
+ the timer hardware is not programmable, then EFI_UNSUPPORTED is
+ returned. If the timer is programmable, then the timer period
+ will be rounded up to the nearest timer period that is supported
+ by the timer hardware. If TimerPeriod is set to 0, then the
+ timer interrupts will be disabled.
+
+ @retval EFI_SUCCESS The timer period was changed.
+ @retval EFI_UNSUPPORTED The platform cannot change the period of the timer interrupt.
+ @retval EFI_DEVICE_ERROR The timer period could not be changed due to a device error.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverSetTimerPeriod (
+ IN EFI_TIMER_ARCH_PROTOCOL *This,
+ IN UINT64 TimerPeriod
+ )
+{
+ UINT64 TimerCount;
+ UINT32 TimerFrequency;
+ UINTN DivideValue = 1;
+
+ if (TimerPeriod == 0) {
+ //
+ // Disable timer interrupt for a TimerPeriod of 0
+ //
+ DisableApicTimerInterrupt();
+ } else {
+ TimerFrequency = PcdGet32(PcdFSBClock) / DivideValue;
+
+ //
+ // Convert TimerPeriod into local APIC counts
+ //
+ // TimerPeriod is in 100ns
+ // TimerPeriod/10000000 will be in seconds.
+ TimerCount = DivU64x32 (MultU64x32 (TimerPeriod, TimerFrequency),
+ 10000000);
+
+ // Check for overflow
+ if (TimerCount > MAX_UINT32) {
+ TimerCount = MAX_UINT32;
+ /* TimerPeriod = (MAX_UINT32 / TimerFrequency) * 10000000; */
+ TimerPeriod = 429496730;
+ }
+
+ //
+ // Program the timer with the new count value
+ //
+ InitializeApicTimer(DivideValue, TimerCount, TRUE, LOCAL_APIC_TIMER_VECTOR);
+
+ //
+ // Enable timer interrupt
+ //
+ EnableApicTimerInterrupt();
+ }
+ //
+ // Save the new timer period
+ //
+ mTimerPeriod = TimerPeriod;
+
+ return EFI_SUCCESS;
+}
+
+/**
+
+ This function retrieves the period of timer interrupts in 100 ns units,
+ returns that value in TimerPeriod, and returns EFI_SUCCESS. If TimerPeriod
+ is NULL, then EFI_INVALID_PARAMETER is returned. If a TimerPeriod of 0 is
+ returned, then the timer is currently disabled.
+
+
+ @param This The EFI_TIMER_ARCH_PROTOCOL instance.
+ @param TimerPeriod A pointer to the timer period to retrieve in 100 ns units. If
+ 0 is returned, then the timer is currently disabled.
+
+ @retval EFI_SUCCESS The timer period was returned in TimerPeriod.
+ @retval EFI_INVALID_PARAMETER TimerPeriod is NULL.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverGetTimerPeriod (
+ IN EFI_TIMER_ARCH_PROTOCOL *This,
+ OUT UINT64 *TimerPeriod
+ )
+{
+ if (TimerPeriod == NULL) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ *TimerPeriod = mTimerPeriod;
+
+ return EFI_SUCCESS;
+}
+
+/**
+
+ This function generates a soft timer interrupt. If the platform does not support soft
+ timer interrupts, then EFI_UNSUPPORTED is returned. Otherwise, EFI_SUCCESS is returned.
+ If a handler has been registered through the EFI_TIMER_ARCH_PROTOCOL.RegisterHandler()
+ service, then a soft timer interrupt will be generated. If the timer interrupt is
+ enabled when this service is called, then the registered handler will be invoked. The
+ registered handler should not be able to distinguish a hardware-generated timer
+ interrupt from a software-generated timer interrupt.
+
+
+ @param This The EFI_TIMER_ARCH_PROTOCOL instance.
+
+ @retval EFI_SUCCESS The soft timer interrupt was generated.
+ @retval EFI_UNSUPPORTED The platform does not support the generation of soft timer interrupts.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverGenerateSoftInterrupt (
+ IN EFI_TIMER_ARCH_PROTOCOL *This
+ )
+{
+ EFI_TPL OriginalTPL;
+
+ if (GetApicTimerInterruptState()) {
+ //
+ // Invoke the registered handler
+ //
+ OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
+
+ if (mTimerNotifyFunction != NULL) {
+ //
+ // @bug : This does not handle missed timer interrupts
+ //
+ mTimerNotifyFunction (mTimerPeriod);
+ }
+
+ gBS->RestoreTPL (OriginalTPL);
+ } else {
+ return EFI_UNSUPPORTED;
+ }
+
+ return EFI_SUCCESS;
+}
+
+/**
+ Initialize the Timer Architectural Protocol driver
+
+ @param ImageHandle ImageHandle of the loaded driver
+ @param SystemTable Pointer to the System Table
+
+ @retval EFI_SUCCESS Timer Architectural Protocol created
+ @retval EFI_OUT_OF_RESOURCES Not enough resources available to initialize driver.
+ @retval EFI_DEVICE_ERROR A device error occurred attempting to initialize the driver.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverInitialize (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ EFI_STATUS Status;
+
+ //
+ // Initialize the pointer to our notify function.
+ //
+ mTimerNotifyFunction = NULL;
+
+ //
+ // Make sure the Timer Architectural Protocol is not already installed in the system
+ //
+ ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, &gEfiTimerArchProtocolGuid);
+
+ //
+ // Find the CPU architectural protocol.
+ //
+ Status = gBS->LocateProtocol (&gEfiCpuArchProtocolGuid, NULL, (VOID **) &mCpu);
+ ASSERT_EFI_ERROR (Status);
+
+ //
+ // Force the timer to be disabled
+ //
+ Status = TimerDriverSetTimerPeriod (&mTimer, 0);
+ ASSERT_EFI_ERROR (Status);
+
+ //
+ // Install interrupt handler for Local APIC Timer
+ //
+ Status = mCpu->RegisterInterruptHandler (mCpu, LOCAL_APIC_TIMER_VECTOR,
+ TimerInterruptHandler);
+ ASSERT_EFI_ERROR (Status);
+
+ //
+ // Force the timer to be enabled at its default period
+ //
+ Status = TimerDriverSetTimerPeriod (&mTimer, DEFAULT_TIMER_TICK_DURATION);
+ ASSERT_EFI_ERROR (Status);
+
+ //
+ // Install the Timer Architectural Protocol onto a new handle
+ //
+ Status = gBS->InstallMultipleProtocolInterfaces (
+ &mTimerHandle,
+ &gEfiTimerArchProtocolGuid, &mTimer,
+ NULL
+ );
+ ASSERT_EFI_ERROR (Status);
+
+ return Status;
+}
+
diff --git a/Maintainers.txt b/Maintainers.txt
index f51731a6b6..78e9f889ab 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -385,6 +385,7 @@ F: OvmfPkg/XenIoPciDxe/
F: OvmfPkg/XenPlatformPei/
F: OvmfPkg/XenPvBlkDxe/
F: OvmfPkg/XenResetVector/
+F: OvmfPkg/XenTimerDxe/
R: Anthony Perard <anthony.perard@citrix.com>
R: Julien Grall <julien.grall@arm.com>
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 30/35] OvmfPkg/OvmfXen: Introduce XenTimerDxe
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 30/35] OvmfPkg/OvmfXen: Introduce XenTimerDxe Anthony PERARD
@ 2019-07-30 12:30 ` Laszlo Ersek
0 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 12:30 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Jordan Justen
On 07/29/19 17:39, Anthony PERARD wrote:
> "OvmfPkg/8254TimerDxe" is replaced with a Xen-specific
> EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
> 8259InterruptControllerDxe as it is not used anymore.
>
> This Timer uses the local APIC timer as time source as it can work on
> both a Xen PVH guest and an HVM one.
>
> Based on the "OvmfPkg/8254TimerDxe" implementation.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - fix the commit message to reflect the fact that the original code as
> moved.
> - Update Maintainers.txt
>
> v3:
> - rebased, SPDX, copyright
>
> v2:
> - Use InitializeApicTimer instead of WriteLocalApicReg
> - rework comments (remove many that don't apply)
> - remove unused includes, and libs
> - have a macro to the timervector.
> - cleanup, copyright
> - rework calculation of TimerCount, value to be use by the APIC timer
> - check for overflow of TimerPeriod, with the apic timer, the period can
> be up to about 42s on Xen (or even higher by changing the DivideValue).
>
> OvmfPkg/OvmfXen.dsc | 3 +-
> OvmfPkg/OvmfXen.fdf | 3 +-
> OvmfPkg/XenTimerDxe/XenTimerDxe.inf | 42 ++++
> OvmfPkg/XenTimerDxe/XenTimerDxe.h | 177 ++++++++++++++
> OvmfPkg/XenTimerDxe/XenTimerDxe.c | 355 ++++++++++++++++++++++++++++
> Maintainers.txt | 1 +
> 6 files changed, 577 insertions(+), 4 deletions(-)
> create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.h
> create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.c
[...]
> diff --git a/Maintainers.txt b/Maintainers.txt
> index f51731a6b6..78e9f889ab 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -385,6 +385,7 @@ F: OvmfPkg/XenIoPciDxe/
> F: OvmfPkg/XenPlatformPei/
> F: OvmfPkg/XenPvBlkDxe/
> F: OvmfPkg/XenResetVector/
> +F: OvmfPkg/XenTimerDxe/
> R: Anthony Perard <anthony.perard@citrix.com>
> R: Julien Grall <julien.grall@arm.com>
>
>
Acked-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (29 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 30/35] OvmfPkg/OvmfXen: Introduce XenTimerDxe Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 12:34 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-08-07 16:00 ` Roger Pau Monné
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 32/35] OvmfPkg: Introduce PcdXenGrantFrames Anthony PERARD
` (5 subsequent siblings)
36 siblings, 2 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemented via SerialDxe.
That is a simple console implementation that can works on both PVH
guest and HVM guests, even if it rarely going to be use on HVM.
Have PlatformBootManagerLib look for the new console, when running as a
Xen guest.
Since we use VENDOR_UART_DEVICE_PATH, fix its description and coding
style.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- instead of creating a new XEN_CONSOLE_DEVICE_PATH, use the existing
VENDOR_UART_DEVICE_PATH. And explain why VENDOR_UART_DEVICE_PATH
changed in the commit message.
v3:
- removed PciSioSerialDxe and IsaSerialDxe from OvmfXen, since they
would not be used, maybe, to check.
- some coding style fix
- not changed: PciSioSerialDxe: even if we add SerialDxe, we still needs
PciSioSerialDxe to have OVMF use the emulated serial port on HVM.
v2:
- Use MdeModulePkg/Universal/SerialDxe instead of something new.
- Have PlatformInitializeConsole() look for it by using the
known-in-advance device path for the xen console in the
PLATFORM_CONSOLE_CONNECT_ENTRY.
OvmfPkg/OvmfXen.dsc | 4 ++
OvmfPkg/OvmfXen.fdf | 1 +
.../PlatformBootManagerLib.inf | 4 ++
.../PlatformBootManagerLib/BdsPlatform.h | 1 +
.../PlatformBootManagerLib/BdsPlatform.c | 3 +-
.../PlatformBootManagerLib/PlatformData.c | 49 +++++++++++++++++--
6 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 54ac910d8e..e719a168f8 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -586,6 +586,10 @@ [Components]
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+ MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
+ <LibraryClasses>
+ SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
+ }
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index fa0830a324..5c1a925d6a 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -312,6 +312,7 @@ [FV.DXEFV]
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 04d614cd49..f89cce1879 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -61,6 +61,10 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
+ gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
+ gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
+ gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity ## CONSUMES
+ gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
[Pcd.IA32, Pcd.X64]
gEfiMdePkgTokenSpaceGuid.PcdFSBClock
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
index 49a072b400..153e215101 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
@@ -165,6 +165,7 @@ typedef struct {
#define CONSOLE_IN BIT1
#define STD_ERROR BIT2
extern PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[];
+extern PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[];
//
// Platform BDS Functions
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 1eba304f09..70df6b841a 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -398,7 +398,8 @@ PlatformBootManagerBeforeConsole (
//
EfiBootManagerDispatchDeferredImages ();
- PlatformInitializeConsole (gPlatformConsole);
+ PlatformInitializeConsole (
+ XenDetected() ? gXenPlatformConsole : gPlatformConsole);
PcdStatus = PcdSet16S (PcdPlatformBootTimeOut,
GetFrontPageTimeoutFromQemu ());
ASSERT_RETURN_ERROR (PcdStatus);
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
index 36aab784d7..2858c3dfd5 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
@@ -9,18 +9,19 @@
#include "BdsPlatform.h"
#include <Guid/QemuRamfb.h>
+#include <Guid/SerialPortLibVendor.h>
//
-// Debug Agent UART Device Path structure
+// Vendor UART Device Path structure
//
-#pragma pack(1)
+#pragma pack (1)
typedef struct {
VENDOR_DEVICE_PATH VendorHardware;
UART_DEVICE_PATH Uart;
VENDOR_DEVICE_PATH TerminalType;
EFI_DEVICE_PATH_PROTOCOL End;
} VENDOR_UART_DEVICE_PATH;
-#pragma pack()
+#pragma pack ()
//
// USB Keyboard Device Path structure
@@ -141,6 +142,37 @@ STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
gEndEntire
};
+STATIC VENDOR_UART_DEVICE_PATH gXenConsoleDevicePath = {
+ {
+ {
+ HARDWARE_DEVICE_PATH,
+ HW_VENDOR_DP,
+ {
+ (UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+ (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+ }
+ },
+ EDKII_SERIAL_PORT_LIB_VENDOR_GUID
+ },
+ {
+ {
+ MESSAGING_DEVICE_PATH,
+ MSG_UART_DP,
+ {
+ (UINT8) (sizeof (UART_DEVICE_PATH)),
+ (UINT8) ((sizeof (UART_DEVICE_PATH)) >> 8)
+ }
+ },
+ 0,
+ FixedPcdGet64 (PcdUartDefaultBaudRate),
+ FixedPcdGet8 (PcdUartDefaultDataBits),
+ FixedPcdGet8 (PcdUartDefaultParity),
+ FixedPcdGet8 (PcdUartDefaultStopBits),
+ },
+ gPcAnsiTerminal,
+ gEndEntire
+};
+
//
// Predefined platform default console device path
//
@@ -163,6 +195,17 @@ PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[] = {
}
};
+PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[] = {
+ {
+ (EFI_DEVICE_PATH_PROTOCOL *)&gXenConsoleDevicePath,
+ (CONSOLE_OUT | CONSOLE_IN | STD_ERROR)
+ },
+ {
+ NULL,
+ 0
+ }
+};
+
//
// Predefined platform connect sequence
//
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn Anthony PERARD
@ 2019-07-30 12:34 ` Laszlo Ersek
2019-08-07 16:00 ` Roger Pau Monné
1 sibling, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 12:34 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Jordan Justen
On 07/29/19 17:39, Anthony PERARD wrote:
> On a Xen PVH guest, none of the existing serial or console interface
> works, so we add a new one, based on XenConsoleSerialPortLib, and
> implemented via SerialDxe.
>
> That is a simple console implementation that can works on both PVH
> guest and HVM guests, even if it rarely going to be use on HVM.
>
> Have PlatformBootManagerLib look for the new console, when running as a
> Xen guest.
>
> Since we use VENDOR_UART_DEVICE_PATH, fix its description and coding
> style.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - instead of creating a new XEN_CONSOLE_DEVICE_PATH, use the existing
> VENDOR_UART_DEVICE_PATH. And explain why VENDOR_UART_DEVICE_PATH
> changed in the commit message.
>
> v3:
> - removed PciSioSerialDxe and IsaSerialDxe from OvmfXen, since they
> would not be used, maybe, to check.
> - some coding style fix
>
> - not changed: PciSioSerialDxe: even if we add SerialDxe, we still needs
> PciSioSerialDxe to have OVMF use the emulated serial port on HVM.
>
> v2:
> - Use MdeModulePkg/Universal/SerialDxe instead of something new.
> - Have PlatformInitializeConsole() look for it by using the
> known-in-advance device path for the xen console in the
> PLATFORM_CONSOLE_CONNECT_ENTRY.
>
> OvmfPkg/OvmfXen.dsc | 4 ++
> OvmfPkg/OvmfXen.fdf | 1 +
> .../PlatformBootManagerLib.inf | 4 ++
> .../PlatformBootManagerLib/BdsPlatform.h | 1 +
> .../PlatformBootManagerLib/BdsPlatform.c | 3 +-
> .../PlatformBootManagerLib/PlatformData.c | 49 +++++++++++++++++--
> 6 files changed, 58 insertions(+), 4 deletions(-)
Looks good, thanks.
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn Anthony PERARD
2019-07-30 12:34 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
@ 2019-08-07 16:00 ` Roger Pau Monné
1 sibling, 0 replies; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 16:00 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Laszlo Ersek, Jordan Justen
On Mon, Jul 29, 2019 at 04:39:40PM +0100, Anthony PERARD wrote:
> On a Xen PVH guest, none of the existing serial or console interface
> works, so we add a new one, based on XenConsoleSerialPortLib, and
> implemented via SerialDxe.
>
> That is a simple console implementation that can works on both PVH
^ work
> guest and HVM guests, even if it rarely going to be use on HVM.
^ is ^ used
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 32/35] OvmfPkg: Introduce PcdXenGrantFrames
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (30 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 12:47 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables Anthony PERARD
` (4 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow
the same value to be used in a different module.
The reason for the number of page to be 4 doesn't exist anymore, so
simply remove the comment.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/OvmfPkg.dec | 3 +++
OvmfPkg/XenBusDxe/XenBusDxe.inf | 2 ++
OvmfPkg/XenBusDxe/XenBusDxe.h | 1 +
OvmfPkg/XenBusDxe/GrantTable.c | 3 +--
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 04d5e29272..d5fee805ef 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -225,6 +225,9 @@ [PcdsFixedAtBuild]
gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|0x0|UINT32|0x17
gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize|0x0|UINT32|0x32
+ ## Number of page frames to use for storing grant table entries.
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames|4|UINT32|0x33
+
[PcdsDynamic, PcdsDynamicEx]
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 86e0fb8224..0b78cd0af4 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -59,3 +59,5 @@ [Protocols]
gXenBusProtocolGuid
gXenIoProtocolGuid
+[FixedPcd]
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
index 8510361bca..b1dcc3549c 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.h
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
@@ -22,6 +22,7 @@
#include <Library/UefiLib.h>
#include <Library/DevicePathLib.h>
#include <Library/DebugLib.h>
+#include <Library/PcdLib.h>
//
diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
index 6575e9b88c..1130404cd1 100644
--- a/OvmfPkg/XenBusDxe/GrantTable.c
+++ b/OvmfPkg/XenBusDxe/GrantTable.c
@@ -22,8 +22,7 @@
#define NR_RESERVED_ENTRIES 8
-/* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
-#define NR_GRANT_FRAMES 4
+#define NR_GRANT_FRAMES (FixedPcdGet32 (PcdXenGrantFrames))
#define NR_GRANT_ENTRIES (NR_GRANT_FRAMES * EFI_PAGE_SIZE / sizeof(grant_entry_v1_t))
STATIC grant_entry_v1_t *GrantTable = NULL;
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 32/35] OvmfPkg: Introduce PcdXenGrantFrames
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 32/35] OvmfPkg: Introduce PcdXenGrantFrames Anthony PERARD
@ 2019-07-30 12:47 ` Laszlo Ersek
0 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 12:47 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Jordan Justen
On 07/29/19 17:39, Anthony PERARD wrote:
> Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow
> the same value to be used in a different module.
>
> The reason for the number of page to be 4 doesn't exist anymore, so
> simply remove the comment.
>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> OvmfPkg/OvmfPkg.dec | 3 +++
> OvmfPkg/XenBusDxe/XenBusDxe.inf | 2 ++
> OvmfPkg/XenBusDxe/XenBusDxe.h | 1 +
> OvmfPkg/XenBusDxe/GrantTable.c | 3 +--
> 4 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 04d5e29272..d5fee805ef 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -225,6 +225,9 @@ [PcdsFixedAtBuild]
> gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|0x0|UINT32|0x17
> gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize|0x0|UINT32|0x32
>
> + ## Number of page frames to use for storing grant table entries.
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames|4|UINT32|0x33
> +
> [PcdsDynamic, PcdsDynamicEx]
> gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
> index 86e0fb8224..0b78cd0af4 100644
> --- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
> @@ -59,3 +59,5 @@ [Protocols]
> gXenBusProtocolGuid
> gXenIoProtocolGuid
>
> +[FixedPcd]
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames
> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
> index 8510361bca..b1dcc3549c 100644
> --- a/OvmfPkg/XenBusDxe/XenBusDxe.h
> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
> @@ -22,6 +22,7 @@
> #include <Library/UefiLib.h>
> #include <Library/DevicePathLib.h>
> #include <Library/DebugLib.h>
> +#include <Library/PcdLib.h>
>
>
> //
Good catch; in my v3 review at
<http://mid.mail-archive.com/4badd535-c23d-c64d-7bb3-fb42bbbf538a@redhat.com>
I didn't realize we'd be introducing the PcdLib dependency anew.
(1) However, in that case, we should list PcdLib in the [LibraryClasses]
section of the INF file as well.
With (1) fixed:
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
There is no need to post v5 just because of this -- if a v5 is otherwise
unnecessary, I can fix this up for you before pushing v4.
Thanks
Laszlo
> diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
> index 6575e9b88c..1130404cd1 100644
> --- a/OvmfPkg/XenBusDxe/GrantTable.c
> +++ b/OvmfPkg/XenBusDxe/GrantTable.c
> @@ -22,8 +22,7 @@
>
> #define NR_RESERVED_ENTRIES 8
>
> -/* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
> -#define NR_GRANT_FRAMES 4
> +#define NR_GRANT_FRAMES (FixedPcdGet32 (PcdXenGrantFrames))
> #define NR_GRANT_ENTRIES (NR_GRANT_FRAMES * EFI_PAGE_SIZE / sizeof(grant_entry_v1_t))
>
> STATIC grant_entry_v1_t *GrantTable = NULL;
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (31 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 32/35] OvmfPkg: Introduce PcdXenGrantFrames Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 13:01 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-08-07 16:07 ` Roger Pau Monné
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 34/35] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg Anthony PERARD
` (3 subsequent siblings)
36 siblings, 2 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
Grant Tables.
The call is only done if it is necessary, we simply detect if the
guest is PVH, as in this case there is currently no PCI bus, and no
PCI Xen platform device which would start the XenIoPciDxe and allocate
the space for the Grant Tables.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Notes:
v4:
- Removed XenIoPvhDxeNotifyExitBoot() which was doing action that should
not be done in an ExitBootServices notification.
(InitializeXenIoPvhDxe() has been cleaned up following this.)
- Use new PcdXenGrantFrames.
- Some coding style fix
- Update Maintainers.txt
v3:
- downgrade type to DXE_DRIVER
- use SPDX
- rework InitializeXenIoPvhDxe, and handle errors properly.
- Free the reserved allocation in ExitBootServices even if the XenIo
protocol could successfully been uninstalled.
v2:
- do allocation in EntryPoint like the other user of XenIoMmioLib.
- allocate memory instead of hardcoded addr.
- cleanup, add copyright
- detect if we are running in PVH mode
OvmfPkg/OvmfXen.dsc | 2 ++
OvmfPkg/OvmfXen.fdf | 1 +
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf | 35 +++++++++++++++++++
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 53 +++++++++++++++++++++++++++++
Maintainers.txt | 1 +
5 files changed, 92 insertions(+)
create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index e719a168f8..5e07b37279 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -195,6 +195,7 @@ [LibraryClasses]
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
+ XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
@@ -583,6 +584,7 @@ [Components]
NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
!endif
}
+ OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 5c1a925d6a..517a492f14 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -309,6 +309,7 @@ [FV.DXEFV]
INF MdeModulePkg/Universal/Metronome/Metronome.inf
INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
new file mode 100644
index 0000000000..5740df6e59
--- /dev/null
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
@@ -0,0 +1,35 @@
+## @file
+# Driver for the XenIo protocol
+#
+# Copyright (c) 2019, Citrix Systems, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION = 0x00010005
+ BASE_NAME = XenIoPvhDxe
+ FILE_GUID = 7a567cc4-0e75-4d7a-a305-c3db109b53ad
+ MODULE_TYPE = DXE_DRIVER
+ VERSION_STRING = 1.0
+ ENTRY_POINT = InitializeXenIoPvhDxe
+
+[Packages]
+ MdePkg/MdePkg.dec
+ OvmfPkg/OvmfPkg.dec
+
+[Sources]
+ XenIoPvhDxe.c
+
+[LibraryClasses]
+ MemoryAllocationLib
+ UefiDriverEntryPoint
+ XenIoMmioLib
+ XenPlatformLib
+
+[FixedPcd]
+ gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames
+
+[Depex]
+ TRUE
diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
new file mode 100644
index 0000000000..e5699cdd80
--- /dev/null
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
@@ -0,0 +1,53 @@
+/** @file
+
+ Driver for the XenIo protocol
+
+ This driver simply allocate space for the grant tables.
+
+ Copyright (c) 2019, Citrix Systems, Inc.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include <Library/MemoryAllocationLib.h>
+#include <Library/XenIoMmioLib.h>
+#include <Library/XenPlatformLib.h>
+
+EFI_STATUS
+EFIAPI
+InitializeXenIoPvhDxe (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ VOID *Allocation;
+ EFI_STATUS Status;
+ EFI_HANDLE XenIoHandle;
+
+ Allocation = NULL;
+ XenIoHandle = NULL;
+
+ if (!XenPvhDetected ()) {
+ return EFI_UNSUPPORTED;
+ }
+
+ Allocation = AllocateReservedPages (FixedPcdGet32 (PcdXenGrantFrames));
+ if (Allocation == NULL) {
+ Status = EFI_OUT_OF_RESOURCES;
+ goto Error;
+ }
+
+ Status = XenIoMmioInstall (&XenIoHandle, (UINTN) Allocation);
+ if (EFI_ERROR (Status)) {
+ goto Error;
+ }
+
+ return EFI_SUCCESS;
+
+Error:
+ if (Allocation != NULL) {
+ FreePages (Allocation, FixedPcdGet32 (PcdXenGrantFrames));
+ }
+ return Status;
+}
diff --git a/Maintainers.txt b/Maintainers.txt
index 78e9f889ab..79defd13bf 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -382,6 +382,7 @@ F: OvmfPkg/PlatformPei/Xen.*
F: OvmfPkg/SmbiosPlatformDxe/*Xen.c
F: OvmfPkg/XenBusDxe/
F: OvmfPkg/XenIoPciDxe/
+F: OvmfPkg/XenIoPvhDxe/
F: OvmfPkg/XenPlatformPei/
F: OvmfPkg/XenPvBlkDxe/
F: OvmfPkg/XenResetVector/
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables Anthony PERARD
@ 2019-07-30 13:01 ` Laszlo Ersek
2019-08-07 16:07 ` Roger Pau Monné
1 sibling, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 13:01 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Jordan Justen
On 07/29/19 17:39, Anthony PERARD wrote:
> XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
> Grant Tables.
>
> The call is only done if it is necessary, we simply detect if the
> guest is PVH, as in this case there is currently no PCI bus, and no
> PCI Xen platform device which would start the XenIoPciDxe and allocate
> the space for the Grant Tables.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>
> Notes:
> v4:
> - Removed XenIoPvhDxeNotifyExitBoot() which was doing action that should
> not be done in an ExitBootServices notification.
> (InitializeXenIoPvhDxe() has been cleaned up following this.)
> - Use new PcdXenGrantFrames.
> - Some coding style fix
> - Update Maintainers.txt
>
> v3:
> - downgrade type to DXE_DRIVER
> - use SPDX
> - rework InitializeXenIoPvhDxe, and handle errors properly.
> - Free the reserved allocation in ExitBootServices even if the XenIo
> protocol could successfully been uninstalled.
>
> v2:
> - do allocation in EntryPoint like the other user of XenIoMmioLib.
> - allocate memory instead of hardcoded addr.
> - cleanup, add copyright
> - detect if we are running in PVH mode
>
> OvmfPkg/OvmfXen.dsc | 2 ++
> OvmfPkg/OvmfXen.fdf | 1 +
> OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf | 35 +++++++++++++++++++
> OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 53 +++++++++++++++++++++++++++++
> Maintainers.txt | 1 +
> 5 files changed, 92 insertions(+)
> create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
>
> diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
> index e719a168f8..5e07b37279 100644
> --- a/OvmfPkg/OvmfXen.dsc
> +++ b/OvmfPkg/OvmfXen.dsc
> @@ -195,6 +195,7 @@ [LibraryClasses]
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> + XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
>
> Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
> TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
> @@ -583,6 +584,7 @@ [Components]
> NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> !endif
> }
> + OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> OvmfPkg/XenBusDxe/XenBusDxe.inf
> OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
> index 5c1a925d6a..517a492f14 100644
> --- a/OvmfPkg/OvmfXen.fdf
> +++ b/OvmfPkg/OvmfXen.fdf
> @@ -309,6 +309,7 @@ [FV.DXEFV]
> INF MdeModulePkg/Universal/Metronome/Metronome.inf
> INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
>
> +INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> INF OvmfPkg/XenBusDxe/XenBusDxe.inf
> INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> new file mode 100644
> index 0000000000..5740df6e59
> --- /dev/null
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> @@ -0,0 +1,35 @@
> +## @file
> +# Driver for the XenIo protocol
> +#
> +# Copyright (c) 2019, Citrix Systems, Inc.
> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> + INF_VERSION = 0x00010005
> + BASE_NAME = XenIoPvhDxe
> + FILE_GUID = 7a567cc4-0e75-4d7a-a305-c3db109b53ad
> + MODULE_TYPE = DXE_DRIVER
> + VERSION_STRING = 1.0
> + ENTRY_POINT = InitializeXenIoPvhDxe
> +
> +[Packages]
> + MdePkg/MdePkg.dec
> + OvmfPkg/OvmfPkg.dec
> +
> +[Sources]
> + XenIoPvhDxe.c
> +
> +[LibraryClasses]
> + MemoryAllocationLib
> + UefiDriverEntryPoint
> + XenIoMmioLib
> + XenPlatformLib
> +
> +[FixedPcd]
> + gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames
> +
> +[Depex]
> + TRUE
> diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> new file mode 100644
> index 0000000000..e5699cdd80
> --- /dev/null
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> @@ -0,0 +1,53 @@
> +/** @file
> +
> + Driver for the XenIo protocol
> +
> + This driver simply allocate space for the grant tables.
> +
> + Copyright (c) 2019, Citrix Systems, Inc.
> +
> + SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include <Library/MemoryAllocationLib.h>
> +#include <Library/XenIoMmioLib.h>
> +#include <Library/XenPlatformLib.h>
> +
> +EFI_STATUS
> +EFIAPI
> +InitializeXenIoPvhDxe (
> + IN EFI_HANDLE ImageHandle,
> + IN EFI_SYSTEM_TABLE *SystemTable
> + )
> +{
> + VOID *Allocation;
> + EFI_STATUS Status;
> + EFI_HANDLE XenIoHandle;
> +
> + Allocation = NULL;
> + XenIoHandle = NULL;
> +
> + if (!XenPvhDetected ()) {
> + return EFI_UNSUPPORTED;
> + }
> +
> + Allocation = AllocateReservedPages (FixedPcdGet32 (PcdXenGrantFrames));
> + if (Allocation == NULL) {
> + Status = EFI_OUT_OF_RESOURCES;
> + goto Error;
> + }
> +
> + Status = XenIoMmioInstall (&XenIoHandle, (UINTN) Allocation);
> + if (EFI_ERROR (Status)) {
> + goto Error;
> + }
> +
> + return EFI_SUCCESS;
> +
> +Error:
> + if (Allocation != NULL) {
> + FreePages (Allocation, FixedPcdGet32 (PcdXenGrantFrames));
> + }
> + return Status;
> +}
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 78e9f889ab..79defd13bf 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -382,6 +382,7 @@ F: OvmfPkg/PlatformPei/Xen.*
> F: OvmfPkg/SmbiosPlatformDxe/*Xen.c
> F: OvmfPkg/XenBusDxe/
> F: OvmfPkg/XenIoPciDxe/
> +F: OvmfPkg/XenIoPvhDxe/
> F: OvmfPkg/XenPlatformPei/
> F: OvmfPkg/XenPvBlkDxe/
> F: OvmfPkg/XenResetVector/
>
(1) We should #include <Library/PcdLib.h> in the "XenIoPvhDxe.c" file,
and list PcdLib in the [LibraryClasses] section of the "XenIoPvhDxe.inf"
file.
With (1) fixed:
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
If v5 doesn't become necessary, I can update this patch for you before
pushing the v4 series; if that's what you prefer.
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables Anthony PERARD
2019-07-30 13:01 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
@ 2019-08-07 16:07 ` Roger Pau Monné
2019-08-08 13:53 ` Anthony PERARD
1 sibling, 1 reply; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 16:07 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Laszlo Ersek, Jordan Justen
On Mon, Jul 29, 2019 at 04:39:42PM +0100, Anthony PERARD wrote:
> XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
> Grant Tables.
>
> The call is only done if it is necessary, we simply detect if the
> guest is PVH, as in this case there is currently no PCI bus, and no
> PCI Xen platform device which would start the XenIoPciDxe and allocate
> the space for the Grant Tables.
Since I'm not familiar with OVMF code, where is the grant table
physical memory coming from then, is it allocated from a hole in the
memory map?
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
2019-08-07 16:07 ` Roger Pau Monné
@ 2019-08-08 13:53 ` Anthony PERARD
0 siblings, 0 replies; 81+ messages in thread
From: Anthony PERARD @ 2019-08-08 13:53 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Wed, Aug 07, 2019 at 06:07:03PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:42PM +0100, Anthony PERARD wrote:
> > XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
> > Grant Tables.
> >
> > The call is only done if it is necessary, we simply detect if the
> > guest is PVH, as in this case there is currently no PCI bus, and no
> > PCI Xen platform device which would start the XenIoPciDxe and allocate
> > the space for the Grant Tables.
>
> Since I'm not familiar with OVMF code, where is the grant table
> physical memory coming from then, is it allocated from a hole in the
> memory map?
On HVM, we use the first BAR of the Xen platform PCI device. Since there
is no such thing on PVH, I simply allocate some memory for it, with
AllocateReservedPages() which mean allocate some pages and tell the OS
to not touch them.
We could deallocate these pages and give them back to the OS but that
would need some refactoring.
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 34/35] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (32 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-07-30 13:05 ` [Xen-devel] [edk2-devel] " Laszlo Ersek
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 35/35] OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg Anthony PERARD
` (2 subsequent siblings)
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used
from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use
RealTimeClockRuntimeDxe from EmbeddedPkg"
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v4:
- Update Maintainers.txt
v3:
- fix the commit message body
ArmVirtPkg/ArmVirtXen.dsc | 2 +-
.../Library/XenRealTimeClockLib/XenRealTimeClockLib.inf | 0
.../Library/XenRealTimeClockLib/XenRealTimeClockLib.c | 0
Maintainers.txt | 2 +-
4 files changed, 2 insertions(+), 2 deletions(-)
rename {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf (100%)
rename {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c (100%)
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 79304ee61d..1b42a9a813 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -27,7 +27,7 @@ [Defines]
[LibraryClasses]
SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
- RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
+ RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
ArmGenericTimerCounterLib|ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
similarity index 100%
rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
similarity index 100%
rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
diff --git a/Maintainers.txt b/Maintainers.txt
index 79defd13bf..919baccc56 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -114,7 +114,6 @@ R: Leif Lindholm <leif.lindholm@linaro.org>
ArmVirtPkg: modules used on Xen
F: ArmVirtPkg/ArmVirtXen.*
F: ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/
-F: ArmVirtPkg/Library/XenRealTimeClockLib/
F: ArmVirtPkg/Library/XenVirtMemInfoLib/
F: ArmVirtPkg/PrePi/
F: ArmVirtPkg/XenAcpiPlatformDxe/
@@ -374,6 +373,7 @@ F: OvmfPkg/Library/XenConsoleSerialPortLib/
F: OvmfPkg/Library/XenHypercallLib/
F: OvmfPkg/Library/XenIoMmioLib/
F: OvmfPkg/Library/XenPlatformLib/
+F: OvmfPkg/Library/XenRealTimeClockLib/
F: OvmfPkg/OvmfXen.*
F: OvmfPkg/OvmfXenElfHeaderGenerator.c
F: OvmfPkg/PlatformPei/MemDetect.c
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 34/35] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 34/35] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg Anthony PERARD
@ 2019-07-30 13:05 ` Laszlo Ersek
0 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 13:05 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Jordan Justen
On 07/29/19 17:39, Anthony PERARD wrote:
> Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used
> from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use
> RealTimeClockRuntimeDxe from EmbeddedPkg"
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v4:
> - Update Maintainers.txt
>
> v3:
> - fix the commit message body
>
> ArmVirtPkg/ArmVirtXen.dsc | 2 +-
> .../Library/XenRealTimeClockLib/XenRealTimeClockLib.inf | 0
> .../Library/XenRealTimeClockLib/XenRealTimeClockLib.c | 0
> Maintainers.txt | 2 +-
> 4 files changed, 2 insertions(+), 2 deletions(-)
> rename {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf (100%)
> rename {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c (100%)
[...]
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 79defd13bf..919baccc56 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -114,7 +114,6 @@ R: Leif Lindholm <leif.lindholm@linaro.org>
> ArmVirtPkg: modules used on Xen
> F: ArmVirtPkg/ArmVirtXen.*
> F: ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/
> -F: ArmVirtPkg/Library/XenRealTimeClockLib/
> F: ArmVirtPkg/Library/XenVirtMemInfoLib/
> F: ArmVirtPkg/PrePi/
> F: ArmVirtPkg/XenAcpiPlatformDxe/
> @@ -374,6 +373,7 @@ F: OvmfPkg/Library/XenConsoleSerialPortLib/
> F: OvmfPkg/Library/XenHypercallLib/
> F: OvmfPkg/Library/XenIoMmioLib/
> F: OvmfPkg/Library/XenPlatformLib/
> +F: OvmfPkg/Library/XenRealTimeClockLib/
> F: OvmfPkg/OvmfXen.*
> F: OvmfPkg/OvmfXenElfHeaderGenerator.c
> F: OvmfPkg/PlatformPei/MemDetect.c
>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [Xen-devel] [PATCH v4 35/35] OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (33 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 34/35] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg Anthony PERARD
@ 2019-07-29 15:39 ` Anthony PERARD
2019-08-07 16:09 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
2019-07-30 12:38 ` [Xen-devel] [edk2-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Laszlo Ersek
2019-07-30 13:10 ` Laszlo Ersek
36 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-07-29 15:39 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Jordan Justen, Julien Grall, Anthony PERARD,
xen-devel, Laszlo Ersek
A Xen PVH guest doesn't have a RTC that OVMF would expect, so
PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
firmware from finish to boot. To prevent that, we will use
XenRealTimeClockLib which simply always return the same time.
This will work on both Xen PVH and HVM guests.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v3:
- moved RealTimeClockLib|*/XenRealTimeClockLib.inf to the global
[LibraryClasses]
OvmfPkg/OvmfXen.dsc | 3 ++-
OvmfPkg/OvmfXen.fdf | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 5e07b37279..5a31f75f05 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -199,6 +199,7 @@ [LibraryClasses]
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+ RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
[LibraryClasses.common]
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -564,7 +565,7 @@ [Components]
}
MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
MdeModulePkg/Universal/Metronome/Metronome.inf
- PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+ EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
<LibraryClasses>
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 517a492f14..e6e9e184ef 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -307,7 +307,7 @@ [FV.DXEFV]
INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
INF MdeModulePkg/Universal/Metronome/Metronome.inf
-INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 35/35] OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 35/35] OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg Anthony PERARD
@ 2019-08-07 16:09 ` Roger Pau Monné
2019-08-08 14:03 ` Anthony PERARD
0 siblings, 1 reply; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-07 16:09 UTC (permalink / raw)
To: devel, anthony.perard
Cc: xen-devel, Julien Grall, Ard Biesheuvel, Laszlo Ersek, Jordan Justen
On Mon, Jul 29, 2019 at 04:39:44PM +0100, Anthony PERARD wrote:
> A Xen PVH guest doesn't have a RTC that OVMF would expect, so
> PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
> firmware from finish to boot. To prevent that, we will use
> XenRealTimeClockLib which simply always return the same time.
> This will work on both Xen PVH and HVM guests.
Not that this is not correct, but what's the point in requiring a
clock if it can be faked by always returning the same value?
It seems like it's usage is not really required, and could indeed be
dropped altogether?
Alternatively, there's the PV clock which is available to PVH guests
and will return a proper time.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 35/35] OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg
2019-08-07 16:09 ` [Xen-devel] [edk2-devel] " Roger Pau Monné
@ 2019-08-08 14:03 ` Anthony PERARD
2019-08-08 15:19 ` Roger Pau Monné
0 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-08-08 14:03 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Wed, Aug 07, 2019 at 06:09:57PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:44PM +0100, Anthony PERARD wrote:
> > A Xen PVH guest doesn't have a RTC that OVMF would expect, so
> > PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
> > firmware from finish to boot. To prevent that, we will use
> > XenRealTimeClockLib which simply always return the same time.
> > This will work on both Xen PVH and HVM guests.
>
> Not that this is not correct, but what's the point in requiring a
> clock if it can be faked by always returning the same value?
It's not a clock that is required, it is a library that implements
RealTimeClockLib. Something needs it, so it is provided, even if it is
only to display the "current time".
> It seems like it's usage is not really required, and could indeed be
> dropped altogether?
Way to much work to drop it. Also, I don't work to fork OVMF.
The ARM implementation of OVMF for Xen does the same thing and simply
always return the same value.
> Alternatively, there's the PV clock which is available to PVH guests
> and will return a proper time.
We might need to do that one day I guess, but right now it is just a
nice to have.
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 35/35] OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg
2019-08-08 14:03 ` Anthony PERARD
@ 2019-08-08 15:19 ` Roger Pau Monné
0 siblings, 0 replies; 81+ messages in thread
From: Roger Pau Monné @ 2019-08-08 15:19 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall, xen-devel,
Laszlo Ersek
On Thu, Aug 08, 2019 at 03:03:48PM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 06:09:57PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:44PM +0100, Anthony PERARD wrote:
> > > A Xen PVH guest doesn't have a RTC that OVMF would expect, so
> > > PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
> > > firmware from finish to boot. To prevent that, we will use
> > > XenRealTimeClockLib which simply always return the same time.
> > > This will work on both Xen PVH and HVM guests.
> >
> > Not that this is not correct, but what's the point in requiring a
> > clock if it can be faked by always returning the same value?
>
> It's not a clock that is required, it is a library that implements
> RealTimeClockLib. Something needs it, so it is provided, even if it is
> only to display the "current time".
>
> > It seems like it's usage is not really required, and could indeed be
> > dropped altogether?
>
> Way to much work to drop it. Also, I don't work to fork OVMF.
>
> The ARM implementation of OVMF for Xen does the same thing and simply
> always return the same value.
>
> > Alternatively, there's the PV clock which is available to PVH guests
> > and will return a proper time.
>
> We might need to do that one day I guess, but right now it is just a
> nice to have.
Ack, thanks for the explanation.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (34 preceding siblings ...)
2019-07-29 15:39 ` [Xen-devel] [PATCH v4 35/35] OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg Anthony PERARD
@ 2019-07-30 12:38 ` Laszlo Ersek
2019-07-30 13:10 ` Laszlo Ersek
36 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 12:38 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Ard Biesheuvel, Andrew Cooper, Julien Grall, Jordan Justen,
xen-devel, Roger Pau Monné
On 07/29/19 17:39, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v4
>
> Changes in v4:
> - patch "OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it has
> run" was removed, and instead a different change is done in
> "OvmfPkg/XenPlatformPei: Rework memory detection"
> - other changes detailed in the notes of each patch
I didn't understand why we'd still have 35 patches with one from v3
removed in v4 -- but I've found the new patch now: "OvmfPkg: Introduce
PcdXenGrantFrames".
Hopefully a v5 will not be necessary, but as a "precaution", you could
run "git notes edit" on patch v4 32/35 at once, in order to state
"introduced in v4", or something similar.
Thanks,
Laszlo
>
> Hi,
>
> I've started to create a Xen specific platform, in OvmfPkg/XenOvmf.dsc
> with the goal to make it work on both Xen HVM and Xen PVH.
>
> The first few patches only create the platform and duplicate some code from
> OvmfPkg and the later patches makes OVMF boot in a Xen PVH guest and can boot
> a Linux guest.
>
> After this patch series, I'd like to wait a bit before removing Xen support
> from the OvmfPkg*.dsc, to allow time to switch to the new Xen only platform,
> maybe 1 year.
>
> To build and boot:
>
> To build, simply run OvmfPkg/build.sh -p OvmfPkg/OvmfXen.dsc
> Then use OVMF.fd as a kernel of a pvh guest config file (with xl/libxl).
>
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v4
>
> Anthony PERARD (35):
> OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
> OvmfPkg: Create platform OvmfXen
> OvmfPkg: Introduce XenResetVector
> OvmfPkg: Introduce XenPlatformPei
> OvmfPkg/OvmfXen: Creating an ELF header
> OvmfPkg/XenResetVector: Add new entry point for Xen PVH
> OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
> OvmfPkg/XenResetVector: Allow jumpstart from either hvmloader or PVH
> OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU
> OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
> OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820
> OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
> OvmfPkg/Library/XenPlatformLib: New library
> OvmfPkg/AcpiPlatformDxe: Use XenPlatformLib
> OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
> OvmfPkg/XenHypercallLib: Enable it in PEIM
> OvmfPkg/XenPlatformPei: Reinit XenHypercallLib
> OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
> OvmfPkg/XenPlatformPei: Setup HyperPages earlier
> OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
> OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
> OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall
> OvmfPkg/XenPlatformPei: Rework memory detection
> OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux
> OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
> OvmfPkg/XenPlatformLib: Cache result for XenDetected
> OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLib
> OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen
> PVH
> OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
> OvmfPkg/OvmfXen: Introduce XenTimerDxe
> OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
> OvmfPkg: Introduce PcdXenGrantFrames
> OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
> OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
> OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg
>
> OvmfPkg/OvmfPkg.dec | 10 +
> ArmVirtPkg/ArmVirtXen.dsc | 2 +-
> OvmfPkg/OvmfPkgIa32.dsc | 1 +
> OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
> OvmfPkg/OvmfPkgX64.dsc | 1 +
> OvmfPkg/{OvmfPkgX64.dsc => OvmfXen.dsc} | 238 +-------
> OvmfPkg/OvmfXen.fdf | 539 ++++++++++++++++++
> OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 3 +-
> .../PlatformBootManagerLib.inf | 6 +-
> .../Library/ResetSystemLib/ResetSystemLib.inf | 1 +
> .../XenHypercallLib/XenHypercallLib.inf | 4 +-
> .../Library/XenPlatformLib/XenPlatformLib.inf | 33 ++
> .../XenRealTimeClockLib.inf | 0
> OvmfPkg/XenBusDxe/XenBusDxe.inf | 2 +
> OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf | 35 ++
> OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 100 ++++
> OvmfPkg/XenResetVector/XenResetVector.inf | 41 ++
> OvmfPkg/XenTimerDxe/XenTimerDxe.inf | 42 ++
> OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h | 6 +-
> OvmfPkg/Include/Guid/XenInfo.h | 8 +-
> .../Xen/arch-x86/hvm/start_info.h | 143 +++++
> OvmfPkg/Include/IndustryStandard/Xen/memory.h | 23 +
> OvmfPkg/Include/Library/XenHypercallLib.h | 12 +
> OvmfPkg/Include/Library/XenPlatformLib.h | 53 ++
> .../PlatformBootManagerLib/BdsPlatform.h | 1 +
> OvmfPkg/XenBusDxe/XenBusDxe.h | 1 +
> OvmfPkg/XenPlatformPei/Cmos.h | 52 ++
> OvmfPkg/XenPlatformPei/Platform.h | 136 +++++
> OvmfPkg/XenPlatformPei/Xen.h | 39 ++
> OvmfPkg/XenTimerDxe/XenTimerDxe.h | 177 ++++++
> OvmfPkg/AcpiPlatformDxe/Xen.c | 41 +-
> .../PlatformBootManagerLib/BdsPlatform.c | 43 +-
> .../PlatformBootManagerLib/PlatformData.c | 49 +-
> .../Library/ResetSystemLib/ResetSystemLib.c | 3 +-
> .../Library/XenHypercallLib/X86XenHypercall.c | 8 +-
> .../Library/XenHypercallLib/XenHypercall.c | 16 +
> .../Library/XenPlatformLib/XenPlatformLib.c | 81 +++
> .../XenRealTimeClockLib/XenRealTimeClockLib.c | 0
> OvmfPkg/OvmfXenElfHeaderGenerator.c | 140 +++++
> OvmfPkg/PlatformPei/Xen.c | 3 -
> OvmfPkg/XenBusDxe/GrantTable.c | 3 +-
> OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 53 ++
> OvmfPkg/XenPlatformPei/AmdSev.c | 64 +++
> OvmfPkg/XenPlatformPei/ClearCache.c | 112 ++++
> OvmfPkg/XenPlatformPei/Cmos.c | 60 ++
> OvmfPkg/XenPlatformPei/Fv.c | 76 +++
> OvmfPkg/XenPlatformPei/MemDetect.c | 490 ++++++++++++++++
> OvmfPkg/XenPlatformPei/Platform.c | 463 +++++++++++++++
> OvmfPkg/XenPlatformPei/Xen.c | 373 ++++++++++++
> OvmfPkg/XenTimerDxe/XenTimerDxe.c | 355 ++++++++++++
> Maintainers.txt | 10 +-
> .../XenResetVector/Ia16/Real16ToFlat32.asm | 137 +++++
> .../XenResetVector/Ia16/ResetVectorVtf0.asm | 79 +++
> .../XenResetVector/Ia32/Flat32ToFlat64.asm | 68 +++
> OvmfPkg/XenResetVector/Ia32/PageTables64.asm | 149 +++++
> .../XenResetVector/Ia32/SearchForBfvBase.asm | 87 +++
> OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 84 +++
> OvmfPkg/XenResetVector/XenResetVector.nasmb | 71 +++
> 58 files changed, 4523 insertions(+), 305 deletions(-)
> copy OvmfPkg/{OvmfPkgX64.dsc => OvmfXen.dsc} (76%)
> create mode 100644 OvmfPkg/OvmfXen.fdf
> create mode 100644 OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> rename {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf (100%)
> create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> create mode 100644 OvmfPkg/XenPlatformPei/XenPlatformPei.inf
> create mode 100644 OvmfPkg/XenResetVector/XenResetVector.inf
> create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.inf
> create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
> create mode 100644 OvmfPkg/Include/Library/XenPlatformLib.h
> create mode 100644 OvmfPkg/XenPlatformPei/Cmos.h
> create mode 100644 OvmfPkg/XenPlatformPei/Platform.h
> create mode 100644 OvmfPkg/XenPlatformPei/Xen.h
> create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.h
> create mode 100644 OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
> rename {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c (100%)
> create mode 100644 OvmfPkg/OvmfXenElfHeaderGenerator.c
> create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> create mode 100644 OvmfPkg/XenPlatformPei/AmdSev.c
> create mode 100644 OvmfPkg/XenPlatformPei/ClearCache.c
> create mode 100644 OvmfPkg/XenPlatformPei/Cmos.c
> create mode 100644 OvmfPkg/XenPlatformPei/Fv.c
> create mode 100644 OvmfPkg/XenPlatformPei/MemDetect.c
> create mode 100644 OvmfPkg/XenPlatformPei/Platform.c
> create mode 100644 OvmfPkg/XenPlatformPei/Xen.c
> create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.c
> create mode 100644 OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> create mode 100644 OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> create mode 100644 OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
> create mode 100644 OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> create mode 100644 OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
> create mode 100644 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> create mode 100644 OvmfPkg/XenResetVector/XenResetVector.nasmb
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests
2019-07-29 15:39 [Xen-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
` (35 preceding siblings ...)
2019-07-30 12:38 ` [Xen-devel] [edk2-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests Laszlo Ersek
@ 2019-07-30 13:10 ` Laszlo Ersek
2019-08-12 15:12 ` Anthony PERARD
36 siblings, 1 reply; 81+ messages in thread
From: Laszlo Ersek @ 2019-07-30 13:10 UTC (permalink / raw)
To: devel, anthony.perard
Cc: Ard Biesheuvel, Andrew Cooper, Julien Grall, Jordan Justen,
xen-devel, Roger Pau Monné
Hi Anthony,
On 07/29/19 17:39, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v4
>
> Changes in v4:
> - patch "OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it has
> run" was removed, and instead a different change is done in
> "OvmfPkg/XenPlatformPei: Rework memory detection"
> - other changes detailed in the notes of each patch
I've gone through the v4 series. If reviewers on the xen-devel list
think v4 is okay to merge, I can do that (with the small fixups I
offered here and there). I suggest that we wait a few days -- please
ping me when you believe the review on xen-devel has concluded.
If you prefer to post v5, that works as well of course.
Thanks,
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [Xen-devel] [edk2-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests
2019-07-30 13:10 ` Laszlo Ersek
@ 2019-08-12 15:12 ` Anthony PERARD
2019-08-13 9:02 ` Laszlo Ersek
0 siblings, 1 reply; 81+ messages in thread
From: Anthony PERARD @ 2019-08-12 15:12 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall,
Andrew Cooper, xen-devel, Roger Pau Monné
On Tue, Jul 30, 2019 at 03:10:13PM +0200, Laszlo Ersek wrote:
> Hi Anthony,
>
> On 07/29/19 17:39, Anthony PERARD wrote:
> > Patch series available in this git branch:
> > https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v4
> >
> > Changes in v4:
> > - patch "OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it has
> > run" was removed, and instead a different change is done in
> > "OvmfPkg/XenPlatformPei: Rework memory detection"
> > - other changes detailed in the notes of each patch
>
> I've gone through the v4 series. If reviewers on the xen-devel list
> think v4 is okay to merge, I can do that (with the small fixups I
> offered here and there). I suggest that we wait a few days -- please
> ping me when you believe the review on xen-devel has concluded.
>
> If you prefer to post v5, that works as well of course.
There's a few more small fixup proposed by Roger, should I post a v5 for
them? (and maybe only CC you and the lists.)
Otherwise, I've pushed the branch br.platform-xen-pvh-v4.1 to my repo [1]
where I believe I've collected all the small fixups.
[1] https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v4.1
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [Xen-devel] [edk2-devel] [PATCH v4 00/35] Specific platform to run OVMF in Xen PVH and HVM guests
2019-08-12 15:12 ` Anthony PERARD
@ 2019-08-13 9:02 ` Laszlo Ersek
0 siblings, 0 replies; 81+ messages in thread
From: Laszlo Ersek @ 2019-08-13 9:02 UTC (permalink / raw)
To: Anthony PERARD
Cc: Ard Biesheuvel, Jordan Justen, devel, Julien Grall,
Andrew Cooper, xen-devel, Roger Pau Monné
On 08/12/19 17:12, Anthony PERARD wrote:
> On Tue, Jul 30, 2019 at 03:10:13PM +0200, Laszlo Ersek wrote:
>> Hi Anthony,
>>
>> On 07/29/19 17:39, Anthony PERARD wrote:
>>> Patch series available in this git branch:
>>> https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v4
>>>
>>> Changes in v4:
>>> - patch "OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it has
>>> run" was removed, and instead a different change is done in
>>> "OvmfPkg/XenPlatformPei: Rework memory detection"
>>> - other changes detailed in the notes of each patch
>>
>> I've gone through the v4 series. If reviewers on the xen-devel list
>> think v4 is okay to merge, I can do that (with the small fixups I
>> offered here and there). I suggest that we wait a few days -- please
>> ping me when you believe the review on xen-devel has concluded.
>>
>> If you prefer to post v5, that works as well of course.
>
> There's a few more small fixup proposed by Roger, should I post a v5 for
> them? (and maybe only CC you and the lists.)
>
> Otherwise, I've pushed the branch br.platform-xen-pvh-v4.1 to my repo [1]
> where I believe I've collected all the small fixups.
> [1] https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v4.1
Please post v5.
Thanks!
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 81+ messages in thread