summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/PlatformPei/Platform.c
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/PlatformPei: remove mFeatureControlValueGerd Hoffmann2022-12-141-1/+1
| | | | | | | | | | | Use PlatformInfoHob->FeatureControlValue instead. OnMpServicesAvailable() will find PlatformInfoHob using GetFirstGuidHob() and pass a pointer to the WriteFeatureControl callback. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: remove mPlatformInfoHobGerd Hoffmann2022-12-141-33/+38
| | | | | | | | | Stop using the mPlatformInfoHob global variable. Let BuildPlatformInfoHob() allocate and return PlatformInfoHob instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: Verification: stop using mPlatformInfoHobGerd Hoffmann2022-12-141-7/+9
| | | | | | | | | | Stop using the mPlatformInfoHob global variable in S3Verification() and Q35BoardVerification() functions. Pass a pointer to the PlatformInfoHob instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: NoExec: stop using mPlatformInfoHobGerd Hoffmann2022-12-141-4/+5
| | | | | | | | | Stop using the mPlatformInfoHob global variable in NoexecDxeInitialization() function. Pass a pointer to the PlatformInfoHob instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: MemTypeInfo: stop using mPlatformInfoHobGerd Hoffmann2022-12-141-1/+1
| | | | | | | | | Stop using the mPlatformInfoHob global variable in MemTypeInfoInitialization() function. Pass a pointer to the PlatformInfoHob instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: PeiMemory: stop using mPlatformInfoHobGerd Hoffmann2022-12-141-1/+1
| | | | | | | | | | Stop using the mPlatformInfoHob global variable in PublishPeiMemory() and GetPeiMemoryCap() functions. Pass a pointer to the PlatformInfoHob instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei Q35 SMM helpers: stop using mPlatformInfoHobGerd Hoffmann2022-12-141-2/+2
| | | | | | | | | | | Stop using the mPlatformInfoHob global variable in Q35TsegMbytesInitialization() and Q35SmramAtDefaultSmbaseInitialization() ) functions. Pass a pointer to the PlatformInfoHob instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: PeiFv: stop using mPlatformInfoHobGerd Hoffmann2022-12-141-1/+1
| | | | | | | | | Stop using the mPlatformInfoHob global variable in PeiFvInitialization() function. Pass a pointer to the PlatformInfoHob instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: AmdSev: stop using mPlatformInfoHobGerd Hoffmann2022-12-141-1/+1
| | | | | | | | | | Stop using the mPlatformInfoHob global variable in AmdSevInitialize() and AmdSevEsInitialize() functions. Pass a pointer to the PlatformInfoHob instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: Update ReserveEmuVariableNvStoreMin M Xu2022-09-061-18/+7
| | | | | | | | | | | | | | | | | | | | | ReserveEmuVariableNvStore is updated with below 2 functions defined in PlatformInitLib: - PlatformReserveEmuVariableNvStore - PlatformInitEmuVariableNvStore PlatformInitEmuVariableNvStore works when secure boot feature is enabled. This is because secure boot needs the EFI variables (PK/KEK/DB/DBX, etc) and EmuVariableNvStore is cleared when OVMF is launched with -bios parameter. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/Microvm/pcie: mPhysMemAddressWidth tweakGerd Hoffmann2022-06-031-1/+1
| | | | | | | | | | | | | | microvm places the 64bit mmio space at the end of the physical address space. So mPhysMemAddressWidth must be correct, otherwise the pci host bridge setup throws an error because it thinks the 64bit mmio window is not addressable. On microvm we can simply use standard cpuid to figure the address width because the host-phys-bits option (-cpu ${name},host-phys-bits=on) is forced to be enabled. Side note: For 'pc' and 'q35' this is not the case for backward compatibility reasons. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Update PlatformPei to support Tdx guestMin Xu2022-04-021-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 OvmfPkg/PlatformPei is updated to support Tdx guest. There are below major changes. - Set Tdx related PCDs - Publish Tdx RamRegions In this patch there is another new function BuildPlatformInfoHob (). This function builds EFI_HOB_PLATFORM_INFO which contains the HostBridgeDevId. The hob is built in both Td guest and Non-Td guest. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformInitLib: Move functions to Platform.cMin Xu2022-04-021-451/+0
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 Move functions in PlatformPei/Platform.c to PlatformInitLib/Platform.c. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformPei: Refactor MiscInitializationMin Xu2022-04-021-17/+26
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 MiscInitialization is split into 2 functions: - PlatformMiscInitialization is for PlatformInitLib. - MiscInitialization calls PlatformMiscInitialization and then sets PCD. It is for PlatformPei. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformPei: Refactor NoexecDxeInitializationMin Xu2022-04-021-13/+21
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 NoexecDxeInitialization is split into 2 functions: - PlatformNoexecDxeInitialization is for PlatformInitLib - NoexecDxeInitialization calls PlatformNoexecDxeInitialization and then sets PCD. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformPei: Refactor MemMapInitializationMin Xu2022-04-021-9/+26
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 MemMapInitialization is split into 2 functions: - PlatformMemMapInitialization is for PlatformInfoLib - MemMapInitialization calls PlatformMemMapInitialization and then sets PCDs. It is for PlatformPei. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformPei: Refactor InitializeRamRegionsMin Xu2022-04-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 InitializeRamRegions is refactored into 3 calls: - PlatformQemuInitializeRam - SevInitializeRam - PlatformQemuInitializeRamForS3 SevInitializeRam is not in PlatformInitLib. Because in the first stage PlatformInitLib only support the basic platform featues. PlatformQemuInitializeRamForS3 wraps the code which was previously in InitializeRamRegions (many code in 2 if-checks). Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformPei: Refactor QemuUc32BaseInitializationMin Xu2022-04-021-1/+1
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 Rename QemuUc32BaseInitialization to PlatformQemuUc32BaseInitialization. This function is for PlatformInitLib. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformPei: Refactor MaxCpuCountInitializationMin Xu2022-04-021-10/+23
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 MaxCpuCountInitialization is splitted into two: - PlatformMaxCpuCountInitialization is for PlatformInitLib - MaxCpuCountInitialization is for PlatformPei. It calls PlatformMaxCpuCountInitialization then sets PCDs. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformPei: Refactor AddressWidthInitializationMin Xu2022-04-021-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 From this patch we start to restruct the functions which set PCDs into two, one for PlatformInitLib, one for PlatformPei. AddressWidthInitialization is the first one. It is splitted into two: - PlatformAddressWidthInitialization is for PlatformInitLib - AddressWidthInitialization is for PlatformPei. It calls PlatformAddressWidthInitialization then set PCDs. Below functions are also refined for PlatformInitLib: - PlatformScanOrAdd64BitE820Ram - PlatformGetSystemMemorySizeAbove4gb - PlatformGetFirstNonAddress All the SetPcd codes are removed from above functions. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformPei: Refactor MiscInitialization for CloudHVMin Xu2022-04-021-7/+6
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 Refactor MiscInitialization for CloudHV to set PCD as other platforms do. Because in the following patch we will split the functions which set PCDs into two, one for PlatformInitLib, one for PlatformPei. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformPei: Refactor MiscInitializationMin Xu2022-04-021-10/+36
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 In MiscInitialization Microvm looks a little weird. Other platforms call PcdSet16S to set the PcdOvmfHostBridgePciDevId with the value same as PlatformInfoHob->HostBridgeDevId. But Microvm doesn't follow this way. In switch-case 0xffff is Microvm, but set with MICROVM_PSEUDO_DEVICE_ID. So we have to add a new function ( MiscInitializationForMicrovm ) for Microvm and delete the code in MiscInitialization. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformPei: Move global variables to PlatformInfoHobMin Xu2022-04-021-51/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 The intention of PlatformInitLib is to extract the common function used in OvmfPkg/PlatformPei. This lib will be used not only in PEI phase but also in SEC phase. SEC phase cannot use global variables between different functions. So PlatformInfoHob is created to hold the informations shared between functions. For example, HostBridgeDevId corespond to mHostBridgeDevId in PlatformPei. In this patch we will first move below global variables to PlatformInfoHob. - mBootMode - mS3Supported - mPhysMemAddressWidth - mMaxCpuCount - mHostBridgeDevId - mQ35SmramAtDefaultSmbase - mQemuUc32Base - mS3AcpiReservedMemorySize - mS3AcpiReservedMemoryBase PlatformInfoHob also holds other information, for example, PciIoBase / PciIoSize. This is because in SEC phase, PcdSetxxx doesn't work. So we will restruct the functions which set PCDs into two, one for PlatformInfoLib, one for PlatformPei. So in this patch we first move global variables and PCDs to PlatformInfoHob. All the changes are in OvmfPkg/PlatformPei. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformInitLib: Add hob functionsMin Xu2022-04-021-90/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 In this patch of PlatformInitLib, below hob functions are introduced: - PlatformAddIoMemoryBaseSizeHob - PlatformAddIoMemoryRangeHob - PlatformAddMemoryBaseSizeHob - PlatformAddMemoryRangeHob - PlatformAddReservedMemoryBaseSizeHob They correspond the below functions in OvmfPkg/PlatformPei: - AddIoMemoryBaseSizeHob - AddIoMemoryRangeHob - AddMemoryBaseSizeHob - AddMemoryRangeHob - AddReservedMemoryBaseSizeHob After above hob functions are introduced in PlatformInitLib, OvmfPkg/PlatformPei is refactored with this library. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Create initial version of PlatformInitLibMin Xu2022-04-021-25/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 There are 3 variants of PlatformPei in OvmfPkg: - OvmfPkg/PlatformPei - OvmfPkg/XenPlatformPei - OvmfPkg/Bhyve/PlatformPei/PlatformPei.inf These PlatformPeis can share many common codes, such as Cmos / Hob / Memory / Platform related functions. This commit (and its following several patches) are to create a PlatformInitLib which wraps the common code called in above PlatformPeis. In this initial version of PlatformInitLib, below Cmos related functions are introduced: - PlatformCmosRead8 - PlatformCmosWrite8 - PlatformDebugDumpCmos They correspond to the functions in OvmfPkg/PlatformPei: - CmosRead8 - CmosWrite8 - DebugDumpCmos Considering this PlatformInitLib will be used in SEC phase, global variables and dynamic PCDs are avoided. We use PlatformInfoHob to exchange information between functions. EFI_HOB_PLATFORM_INFO is the data struct which contains the platform information, such as HostBridgeDevId, BootMode, S3Supported, SmmSmramRequire, etc. After PlatformInitLib is created, OvmfPkg/PlatformPei is refactored with this library. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/Microvm/fdt: add empty fdtGerd Hoffmann2021-12-131-4/+22
| | | | | | | | | | | | | | | | | | | | FdtClient is unhappy without a device tree, so add an empty fdt which we can use in case etc/fdt is not present in fw_cfg. On ARM machines a device tree is mandatory for hardware detection, that's why FdtClient fails hard. On microvm the device tree is only used to detect virtio-mmio devices (this patch series) and the pcie host (future series). So edk2 can continue with limited functionality in case no device tree is present: no storage, no network, but serial console and direct kernel boot works. qemu release 6.2 & newer will provide a device tree for microvm. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/Microvm/fdt: load fdt from fw_cfgGerd Hoffmann2021-12-131-0/+45
| | | | | | | | | | | | Needed for hardware detection: virtio-mmio devices for now, later also pcie root bridge. Depends on patched qemu which actually provides an fdt: https://gitlab.com/kraxel/qemu/-/commits/sirius/microvm-device-tree Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg: Handle Cloud Hypervisor host bridgeSebastien Boeuf2021-12-111-0/+8
| | | | | | | | | | Handle things differently when the detected host bridge matches the Cloud Hypervisor PCI host bridge identifier. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Rob Bradford <robert.bradford@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg: Apply uncrustify changesMichael Kubacki2021-12-071-107/+135
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the OvmfPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
* OvmfPkg/ResetSystemLib: add driver for microvmGerd Hoffmann2021-10-051-0/+1
| | | | | | | | Uses the generic event device to reset and poweroff. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3599 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/Microvm: PlatformPei/Platform: add id.Gerd Hoffmann2021-10-051-0/+7
| | | | | | | | Add + set microvm id for PcdOvmfHostBridgePciDevId. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3599 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/Microvm: PlatformPei/Platform memory map tweaksGerd Hoffmann2021-10-051-0/+6
| | | | | | | | Microvm needs ioapic hobs only. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3599 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/PlatformPei: remove Xen supportLaszlo Ersek2021-06-041-87/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "OvmfPkg/PlatformPei/PlatformPei.inf" module is used by the following platform DSCs: OvmfPkg/AmdSev/AmdSevX64.dsc OvmfPkg/OvmfPkgIa32.dsc OvmfPkg/OvmfPkgIa32X64.dsc OvmfPkg/OvmfPkgX64.dsc Remove Xen support from "OvmfPkg/PlatformPei", including any dependencies that now become unused. The basic idea is to substitute FALSE for "mXen". Remove "OvmfPkg/PlatformPei" from the "OvmfPkg: Xen-related modules" section of "Maintainers.txt". This patch is best reviewed with "git show -b -W". Cc: Andrew Fish <afish@apple.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-22-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: replace old EFI_D_ debug levels with new DEBUG_ onesRebecca Cran2020-04-301-11/+11
| | | | | | | | | | | | | Generated mechanically with: find OvmfPkg -type f -exec sed -i -e 's/EFI_D_/DEBUG_/g' {} \; Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200429215327.606467-1-rebecca@bsdio.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformPei: use QemuFwCfgParseBool in UPDATE_BOOLEAN_PCD_FROM_...Laszlo Ersek2020-04-281-45/+2
| | | | | | | | | | | | | | | | | | The UPDATE_BOOLEAN_PCD_FROM_FW_CFG() macro currently calls the module-private helper function GetNamedFwCfgBoolean(). Replace the latter with QemuFwCfgParseBool() from QemuFwCfgSimpleParserLib. This change is compatible with valid strings accepted previously. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: remove handling of properties tableArd Biesheuvel2020-04-071-1/+0
| | | | | | | | | | | | | | The UEFI properties table and the associated memory protection feature was severely broken from the start, and has been deprecated for a while. Let's drop all references to it from OVMF so we can safely remove it from the DXE core as well. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformationLaszlo Ersek2020-03-121-22/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * In the Intel whitepaper: --v-- A Tour Beyond BIOS -- Secure SMM Communication https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Secure_SMM_Communication.pdf --^-- bullet#3 in section "Assumption and Recommendation", and bullet#4 in "Call for action", recommend enabling the (adaptive) Memory Type Information feature. * In the Intel whitepaper: --v-- A Tour Beyond BIOS -- Memory Map and Practices in UEFI BIOS https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-white-papers https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf --^-- figure#6 describes the Memory Type Information feature in detail; namely as a feedback loop between the Platform PEIM, the DXE IPL PEIM, the DXE Core, and BDS. Implement the missing PlatformPei functionality in OvmfPkg, for fulfilling the Secure SMM Communication recommendation. In the longer term, OVMF should install the WSMT ACPI table, and this patch contributes to that. Notes: - the step in figure#6 where the UEFI variable is copied into the HOB is covered by the DXE IPL PEIM, in the DxeLoadCore() function, - "PcdResetOnMemoryTypeInformationChange" must be reverted to the DEC default TRUE value, because both whitepapers indicate that BDS needs to reset the system if the Memory Type Information changes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-6-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton)Laszlo Ersek2020-02-051-0/+1
| | | | | | | | | | | | | | | | | Introduce the Q35SmramAtDefaultSmbaseInitialization() function for detecting the "SMRAM at default SMBASE" feature. For now, the function is only a skeleton, so that we can gradually build upon the result while the result is hard-coded as FALSE. The actual detection will occur in a later patch. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: factor out Q35BoardVerification()Laszlo Ersek2020-02-051-0/+23
| | | | | | | | | | | | | | Before adding another SMM-related, and therefore Q35-only, dynamically detectable feature, extract the current board type check from Q35TsegMbytesInitialization() to a standalone function. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplugLaszlo Ersek2020-01-291-24/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MaxCpuCountInitialization() currently handles the following options: (1) QEMU does not report the boot CPU count (FW_CFG_NB_CPUS is 0) In this case, PlatformPei makes MpInitLib enumerate APs up to the default PcdCpuMaxLogicalProcessorNumber value (64) minus 1, or until the default PcdCpuApInitTimeOutInMicroSeconds (50,000) elapses. (Whichever is reached first.) Time-limited AP enumeration had never been reliable on QEMU/KVM, which is why commit 45a70db3c3a5 strated handling case (2) below, in OVMF. (2) QEMU reports the boot CPU count (FW_CFG_NB_CPUS is nonzero) In this case, PlatformPei sets - PcdCpuMaxLogicalProcessorNumber to the reported boot CPU count (FW_CFG_NB_CPUS, which exports "PCMachineState.boot_cpus"), - and PcdCpuApInitTimeOutInMicroSeconds to practically "infinity" (MAX_UINT32, ~71 minutes). That causes MpInitLib to enumerate exactly the present (boot) APs. With CPU hotplug in mind, this method is not good enough. Because, using QEMU terminology, UefiCpuPkg expects PcdCpuMaxLogicalProcessorNumber to provide the "possible CPUs" count ("MachineState.smp.max_cpus"), which includes present and not present CPUs both (with not present CPUs being subject for hot-plugging). FW_CFG_NB_CPUS does not include not present CPUs. Rewrite MaxCpuCountInitialization() for handling the following cases: (1) The behavior of case (1) does not change. (No UefiCpuPkg PCDs are set to values different from the defaults.) (2) QEMU reports the boot CPU count ("PCMachineState.boot_cpus", via FW_CFG_NB_CPUS), but not the possible CPUs count ("MachineState.smp.max_cpus"). In this case, the behavior remains unchanged. The way MpInitLib is instructed to do the same differs however: we now set the new PcdCpuBootLogicalProcessorNumber to the boot CPU count (while continuing to set PcdCpuMaxLogicalProcessorNumber identically). PcdCpuApInitTimeOutInMicroSeconds becomes irrelevant. (3) QEMU reports both the boot CPU count ("PCMachineState.boot_cpus", via FW_CFG_NB_CPUS), and the possible CPUs count ("MachineState.smp.max_cpus"). We tell UefiCpuPkg about the possible CPUs count through PcdCpuMaxLogicalProcessorNumber. We also tell MpInitLib the boot CPU count for precise and quick AP enumeration, via PcdCpuBootLogicalProcessorNumber. PcdCpuApInitTimeOutInMicroSeconds is irrelevant again. This patch is a pre-requisite for enabling CPU hotplug with SMM_REQUIRE. As a side effect, the patch also enables S3 to work with CPU hotplug at once, *without* SMM_REQUIRE. (Without the patch, S3 resume fails, if a CPU is hot-plugged at OS runtime, prior to suspend: the FW_CFG_NB_CPUS increase seen during resume causes PcdCpuMaxLogicalProcessorNumber to increase as well, which is not permitted. With the patch, PcdCpuMaxLogicalProcessorNumber stays the same, namely "MachineState.smp.max_cpus". Therefore, the CPU structures allocated during normal boot can accommodate the CPUs at S3 resume that have been hotplugged prior to S3 suspend.) Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20191022221554.14963-4-lersek@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: set 32-bit UC area at PciBase / PciExBarBase (pc/q35)Laszlo Ersek2019-06-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (This is a replacement for commit 39b9a5ffe661 ("OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many bits clear", 2019-05-16).) Reintroduce the same logic as seen in commit 39b9a5ffe661 for the pc (i440fx) board type. For q35, the same approach doesn't work any longer, given that (a) we'd like to keep the PCIEXBAR in the platform DSC a fixed-at-build PCD, and (b) QEMU expects the PCIEXBAR to reside at a lower address than the 32-bit PCI MMIO aperture. Therefore, introduce a helper function for determining the 32-bit "uncacheable" (MMIO) area base address: - On q35, this function behaves statically. Furthermore, the MTRR setup exploits that the range [0xB000_0000, 0xFFFF_FFFF] can be marked UC with just two variable MTRRs (one at 0xB000_0000 (size 256MB), another at 0xC000_0000 (size 1GB)). - On pc (i440fx), the function behaves dynamically, implementing the same logic as commit 39b9a5ffe661 did. The PciBase value is adjusted to the value calculated, similarly to commit 39b9a5ffe661. A further simplification is that we show that the UC32 area size truncation to a whole power of two automatically guarantees a >=2GB base address. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* Revert "OvmfPkg/PlatformPei: assign PciSize on both i440fx/q35 branches ↵Laszlo Ersek2019-06-031-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | explicitly" This reverts commit 60e95bf5094fbb9b728729ccfaf32184b3662317. The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814> triggered a bug / incorrect assumption in QEMU. QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above it. When the firmware doesn't satisfy this assumption, QEMU generates an \_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign 32-bit MMIO BARs. Working around the problem in the firmware looks less problematic than fixing QEMU. Revert the original changes first, before implementing an alternative fix. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* Revert "OvmfPkg/PlatformPei: hoist PciBase assignment above the i440fx/q35 ↵Laszlo Ersek2019-06-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | branching" This reverts commit 9a2e8d7c65ef7f39c6754d27e52954b616bc6628. The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814> triggered a bug / incorrect assumption in QEMU. QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above it. When the firmware doesn't satisfy this assumption, QEMU generates an \_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign 32-bit MMIO BARs. Working around the problem in the firmware looks less problematic than fixing QEMU. Revert the original changes first, before implementing an alternative fix. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* Revert "OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the PCIEXBAR ↵Laszlo Ersek2019-06-031-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | on q35" This reverts commit 75136b29541b0e093a51d2e2c2af8d19855c2b60. The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814> triggered a bug / incorrect assumption in QEMU. QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above it. When the firmware doesn't satisfy this assumption, QEMU generates an \_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign 32-bit MMIO BARs. Working around the problem in the firmware looks less problematic than fixing QEMU. Revert the original changes first, before implementing an alternative fix. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* Revert "OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many bits ↵Laszlo Ersek2019-06-031-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | clear" This reverts commit 39b9a5ffe6618b7870be2a54fe7725000249c33a. The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814> triggered a bug / incorrect assumption in QEMU. QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above it. When the firmware doesn't satisfy this assumption, QEMU generates an \_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign 32-bit MMIO BARs. Working around the problem in the firmware looks less problematic than fixing QEMU. Revert the original changes first, before implementing an alternative fix. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many bits clearLaszlo Ersek2019-05-161-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assume that we boot OVMF in a QEMU guest with 1025 MB of RAM. The following assertion will fire: > ASSERT_EFI_ERROR (Status = Out of Resources) > ASSERT OvmfPkg/PlatformPei/MemDetect.c(696): !EFI_ERROR (Status) That's because the range [1025 MB, 4 GB) that we try to mark as uncacheable with MTRRs has size 3071 MB: 0x1_0000_0000 -0x0_4010_0000 -------------- 0x0_BFF0_0000 The integer that stands for the uncacheable area size has 11 (eleven) bits set to 1. As a result, covering this size requires 11 variable MTRRs (each MTRR must cover a naturally aligned, power-of-two sized area). But, if we need more variable MTRRs than the CPU can muster (such as 8), then MtrrSetMemoryAttribute() fails, and we refuse to continue booting (which is justified, in itself). Unfortunately, this is not difficult to trigger, and the error message is well-hidden from end-users, in the OVMF debug log. The following mitigation is inspired by SeaBIOS: Truncate the uncacheable area size to a power-of-two, while keeping the end fixed at 4 GB. Such an interval can be covered by just one variable MTRR. This may leave such an MMIO gap, between the end of low-RAM and the start of the uncacheable area, that is marked as WB (through the MTRR default). Raise the base of the 32-bit PCI MMIO aperture accordingly -- the gap will not be used for anything. On Q35, the minimal 32-bit PCI MMIO aperture (triggered by RAM size 2815 MB) shrinks from 0xE000_0000 - 0xAFF0_0000 = 769 MB to 0xE000_0000 - 0xC000_0000 = 512 MB On i440fx, the minimal 32-bit PCI MMIO aperture (triggered by RAM size 3583 MB) shrinks from 0xFC00_0000 - 0xDFF0_0000 = 449 MB to 0xFC00_0000 - 0xE000_0000 = 448 MB Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the PCIEXBAR on q35Laszlo Ersek2019-05-161-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 7b8fe63561b4 ("OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35", 2016-03-10) claimed that, On Q35 machine types that QEMU intends to support in the long term, QEMU never lets the RAM below 4 GB exceed 2 GB. Alas, this statement came from a misunderstanding that occurred while we worked out the interface contract. In fact QEMU does allow the 32-bit RAM extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than 2048MB and smaller than 2816MB). In turn, such a RAM size (justifiedly) triggers ASSERT (TopOfLowRam <= PciExBarBase); in MemMapInitialization(), because we placed the 256MB PCIEXBAR at 0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the 32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000, 0xFC00_0000) range.) In order to fix this, reorder the 32-bit PCI window against the PCIEXBAR, as follows: - start the 32-bit PCI window where it starts on i440fx as well, that is, at 2GB or TopOfLowRam, whichever is higher; - unlike on i440fx, where the 32-bit PCI window extends up to 0xFC00_0000, stop it at 0xE000_0000 on q35, - place the PCIEXBAR at 0xE000_0000. (We cannot place the PCIEXBAR at 0xF000_0000 because the 256MB MMIO area that starts there is not entirely free.) Before this patch, the 32-bit PCI window used to only *end* at the same spot (namely, 0xFC00_0000) between i440fx and q35; now it will only *start* at the same spot (namely, 2GB or TopOfLowRam, whichever is higher) between both boards. On q35, the maximal window shrinks from 0xFC00_0000 - 0x9000_0000 = 0x6C00_0000 == 1728 MB to 0xE000_0000 - 0x8000_0000 == 1536 MB. We lose 192 MB of the aperture; however, the aperture is now aligned at 1GB, rather than 256 MB, and so it could fit a 1GB BAR even. Regarding the minimal window (triggered by RAM size 2815MB), its size is 0xE000_0000 - 0xAFF0_0000 = 769 MB which is not great, but probably better than a failed ASSERT. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformPei: hoist PciBase assignment above the i440fx/q35 branchingLaszlo Ersek2019-05-161-1/+1
| | | | | | | | | | | | | | | | | | | | In the MemMapInitialization() function, we currently assign PciBase different values, on both branches of the board type check. Hoist the PciBase assignment from the i440fx branch in front of the "if". This is a no-op for the i440fx branch. On the q35 branch, we overwrite this value, hence the change is a no-op on q35 as well. This is another refactoring for simplifying the rest of this series. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: assign PciSize on both i440fx/q35 branches explicitlyLaszlo Ersek2019-05-161-1/+2
| | | | | | | | | | | | | | | | | In the MemMapInitialization() function, we currently have a common PciSize assignment, shared between i440fx and q35. In order to simplify the rest of this series, lift and duplicate the assignment identically to both board-specific branches. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-091-7/+1
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-28 06:28:47 +0000