summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* BaseTools: Fixed the bug of multi-thread genffs for override infFeng, Bob C2019-09-114-7/+10
| | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1302 If there is a inf override, and multi-thread genffs is enabled, build will fail. This patch is going to fix this bug. Cc: Liming Gao <liming.gao@intel.com> Cc: Steven Shi <steven.shi@intel.com> Signed-off-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Sort Pcd settings to make PcdTokenNumber be fixedFeng, Bob C2019-09-102-1/+12
| | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2147 This patch is to sort the Pcd settings so that PcdTokenNumber will not change if the platform's Pcd settings are the same. Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Steven Shi <steven.shi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Fixed issue for IgnoreAutoGenFeng, Bob C2019-09-106-136/+253
| | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2080 This patch is to improve build -u option to re-use GlobalVar_<platformguid>_<arch>.bin file which is introduced by multiple-process-autogen feature. Cc: Liming Gao <liming.gao@intel.com> Cc: Steven Shi <steven.shi@intel.com> Signed-off-by: Bob Feng <bob.c.feng@intel.com> Acked-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Fixed build clean regression issueFeng, Bob C2019-09-101-5/+3
| | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2166 file_lock and cache_lock are used as global data, so move file_lock and cache_lock initialization in Build object __init__ function. Cc: Liming Gao <liming.gao@intel.com> Cc: Steven Shi <steven.shi@intel.com> Signed-off-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Fix a bug for Hii Pcd overrideBob Feng2019-09-101-2/+2
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2157 Hii Pcd links to a efi variable. The Variable default value is evaluated by related Hii Pcds setting. If multiple Hii Pcds links to one variable, and the offset overlap, the later Hii Pcds setting should be effective. There is a tool bug that is if the Pcds are in different dsc file which are included into the platform dsc file, build tool does not get the Pcds relative position correctly. That means build tool does not know which Pcd is the later one. As the result, the variable default value will be incorrect. This patch is to fix this bug. Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdePkg/BluetoothLeConfig.h: Add type EfiBluetoothSmpPeerAddressListRay Ni2019-09-101-1/+3
| | | | | | | | | | | | To support auto-connection, EFI_BLUETOOTH_LE_SMP_DATA_TYPE needs to add a new data type EfiBluetoothSmpPeerAddressList which associates with a list of Bluetooth per address connected before. This new data type was added in UEFI spec 2.7b. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools:ECC need to handle lower case 'static'Fan, ZhijuX2019-09-094-4/+4
| | | | | | | | | | | | | | | | | | BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1778 We are going to add keyword (lower case) 'static' for functions and global variables which are not referenced outside their current C file. However, the ECC tool only recognizes upper case 'STATIC' at this moment. This will lead to issue reports for new codes that follow the above coding style. This patch is going to handle lower case 'static' Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools:Ecc handle another copyright formatFan, ZhijuX2019-09-091-1/+1
| | | | | | | | | | | | | | | | | BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2057 Ecc can not handle the copyright format like (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP<BR> This will cause Ecc to report wrong information. This patch is going to handle this format Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* OvmfPkg/EnrollDefaultKeys: clean up Base64Decode() retval handlingLaszlo Ersek2019-09-051-8/+2
| | | | | | | | | | | | | | | | | Since commit 35e242b698cd ("MdePkg/BaseLib: rewrite Base64Decode()", 2019-07-16), Base64Decode() guarantees that DestinationSize is larger on output than it was on input if RETURN_BUFFER_TOO_SMALL is returned. Clean up the retval handling for the first Base64Decode() call in EnrollDefaultKeys, which used to work around the ambiguity in the previous Base64Decode() interface contract. 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=1981 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* ArmVirtPkg/PlatformBootManagerLib: unload image on EFI_SECURITY_VIOLATIONLaszlo Ersek2019-09-051-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LoadImage() boot service is a bit unusual in that it allocates resources in a particular failure case; namely, it produces a valid "ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to happen e.g. when Secure Boot verification fails for the image, but the platform policy for the particular image origin (such as "fixed media" or "removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code allows platform logic to selectively override the verification failure, and launch the image nonetheless. ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION for the kernel image loaded from fw_cfg -- any LoadImage() error is considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any other LoadImage() error, we leak the resources associated with "KernelImageHandle". From a resource usage perspective, EFI_SECURITY_VIOLATION must be considered "success", and rolled back. Implement this rollback, without breaking the proper "nesting" of error handling jumps and labels. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992 Fixes: 23d04b58e27b382bbd3f9b16ba9adb1cb203dad5 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* ShellPkg/ShellPkg.dsc AARCH64: enable stack protectorArd Biesheuvel2019-09-051-4/+1
| | | | | | | | | | Incorporate the stack protector library into the AARCH64 build of the Shell binaries as a NULL library resolution, to avoid build errors when the compiler injects stack integrity checks. Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linkingArd Biesheuvel2019-09-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | In some cases, the CLANG38 toolchain profile in LTO mode emits GOT based relocations in spite of our attempts to avoid this, by using hidden visibility, -Bsymbolic etc. On AARCH64, we managed to work around this by processing the GOT based relocations in GenFw. As it turns out, the same issue exists on 32-bit ARM, but unfortunately, we cannot use a similar trick to get rid of the GOT entry, and the relocation metadata is insufficient to locate the GOT entry in the binary. Note that in this particular case, we are interested in PIE linking only (i.e., producing a .rela section containing dynamic relocations that the startup code can process directly), and not in position independent code generation, and by passing the -pie option to the linker directly using -Wl,-pie (and dropping -shared), we can coerce the GOLD linker into doing only the former rather than both when it performs its LTO code generation. Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* UefiCpuPkg: support single EFI_PEI_CORE_FV_LOCATION_PPI in PpiListChasel Chiu2019-09-051-5/+4
| | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2153 Current logic will skip searching EFI_PEI_CORE_FV_LOCATION_PPI when the PPI in PpiList having EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag, but platform may pass single PPI in PpiList that should be supported. Changed the logic to verify PpiList first before checking EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag. Test: Verified both single EFI_PEI_CORE_FV_LOCATION_PPI and multiple PPIs in PpiList cases and both can boot with the PeiCore specified by EFI_PEI_CORE_FV_LOCATION_PPI. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* IntelFsp2WrapperPkg: Remove unneeded MdeModulePkg dependencyRay Ni2019-09-052-6/+2
| | | | | | | Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* IntelFsp2Pkg/FspSecCore: Remove unneeded MdeModulePkg dependencyRay Ni2019-09-053-4/+1
| | | | | | | Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* BaseTools/GenFw AARCH64: fix up GOT based relative relocationsArd Biesheuvel2019-09-041-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We take great care to avoid GOT based relocations in EDK2 executables, primarily because they are pointless - we don't care about things like the CoW footprint or relocations that target read-only sections, and so GOT entries only bloat the binary. However, in some cases (e.g., when building the relocatable PrePi SEC module in ArmVirtPkg with the CLANG38 toolchain), we may end up with some GOT based relocations nonetheless, which break the build since GenFw does not know how to deal with them. The relocations emitted in this case are ADRP/LDR instruction pairs that are annotated as GOT based, which means that it is the linker's job to emit the GOT entry and tag it with an appropriate dynamic relocation that ensures that the correct absolute value is stored into the GOT entry when the executable is loaded. This dynamic relocation is not visible to GenFw, and so populating the PE/COFF relocation section for these entries is non-trivial. Since each ADRP/LDR pair refers to a single symbol that is local to the binary (given that shared libraries are not supported), we can actually convert the ADRP/LDR pair into an ADRP/ADD pair that produces the symbol address directly rather than loading it from memory. This leaves the GOT entry in the binary, but since it is now unused, it is no longer necessary to emit a PE/COFF relocation entry for it. Acked-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* ShellPkg/Pci.c: Update supported link speed to PCI5.0Gao, Zhichao2019-09-041-2/+14
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1955 Refer to PCI express base specification Reversion 5.0, Version 1.0, Table 7-33, Supported Link Speeds Vector bit 3 indicate the speed 16 GT/s and bit 4 indicate the speed 32 GT/s. Add the support to shell command 'pci ...'. Change the MaxLinkSpeed other values' result from 'Unknown' to 'Reserved' to make the result align. Cc: Ray Ni <ray.ni@intel.com> Cc: Oleksiy <oleksiyy@ami.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* BaseTools: Update GenFw tool to support -e -z option togetherLiming Gao2019-09-041-2/+15
| | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1727 -e -z option is to generate EFI image with zero debug entry. It can be used to check the EFI image in DEBUG build. This fix also supports the case -t -z option together for TE image. Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
* MdeModulePkg: Remove PcdRealTimeClockUpdateTimeoutRay Ni2019-09-042-8/+0
| | | | | | | | | | The PCD is moved to PcAtChipsetPkg so remove it from MdeModulePkg. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com>
* PcAtChipsetPkg: add PcdRealTimeClockUpdateTimeoutRay Ni2019-09-043-4/+10
| | | | | | | | | | | | PcdRealTimeClockUpdateTimeout is now defined in MdeModulePkg.dec. This is the only reason that causes PcAtChipsetPkg depends on MdeModulePkg. Move the PCD from MdeModulePkg.dec to PcAtChipsetPkg.dec removes such dependency. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg: Explain relationship between several SMM PCDsRay Ni2019-09-041-1/+7
| | | | | | | | | | | | | | | There are three PCDs that may impact the behavior of each other in SMM environment: PcdCpuSmmProfileEnable PcdHeapGuardPropertyMask in MdeModulePkg PcdCpuSmmRestrictedMemoryAccess The patch updates the comments in DEC file to document it. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpu: Restrict access per PcdCpuSmmRestrictedMemoryAccessRay Ni2019-09-044-8/+49
| | | | | | | | | | | | | | | | | | Today's behavior is to always restrict access to non-SMRAM regardless the value of PcdCpuSmmRestrictedMemoryAccess. Because RAS components require to access all non-SMRAM memory, the patch changes the code logic to honor PcdCpuSmmRestrictedMemoryAccess so that only when the PCD is true, the restriction takes affect and page table memory is also protected. Because IA32 build doesn't reference this PCD, such restriction always takes affect in IA32 build. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpu: Use new PCD PcdCpuSmmRestrictedMemoryAccessRay Ni2019-09-042-22/+34
| | | | | | | | | | | | | | | The patch changes PiSmmCpu driver to consume PCD PcdCpuSmmRestrictedMemoryAccess. Because the behavior controlled by PcdCpuSmmStaticPageTable in original code is not changed after switching to PcdCpuSmmRestrictedMemoryAccess. The functionality is not impacted by this patch. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Add PcdCpuSmmRestrictedMemoryAccessRay Ni2019-09-041-0/+12
| | | | | | | | | | | | | | | | | | The patch adds a new X64 only PCD PcdCpuSmmRestrictedMemoryAccess. The PCD indicates access to non-SMRAM memory is restricted to reserved, runtime and ACPI NVS type after SmmReadyToLock. MMIO access is always allowed regardless of the value of this PCD. Loose of such restriction is only required by RAS components in X64 platforms. The PCD value is considered as constantly TRUE in IA32 platforms. When the PCD value is TRUE, page table is initialized to cover all memory spaces and the memory occupied by page table is protected by page table itself as read-only. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* ShellPkg/CommandLib: avoid NULL derefence and memory leakHeinrich Schuchardt2019-09-031-6/+14
| | | | | | | | | | | | | | | | | | | Since TianoCore EDK2 commit d65f2cea36d1 ("ShellPkg/CommandLib: Locate proper UnicodeCollation instance") in edk2 the UEFI Shell crashes if EFI variable PlatformLang is not defined due to dereferencing gUnicodeCollation gUnicodeCollation (= NULL) in ShellCommandRegisterCommandName(). Furthermore CommandInit() is leaking PlatformLang if gUnicodeCollation != NULL. Close the memory leak and use the first UnicodeCollation instance if PlatfomLang is not defined. Fixes: d65f2cea36d1 ("ShellPkg/CommandLib: Locate proper UnicodeCollation instance") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
* MdePkg/DxeHstiLib: Added checks to improve error handling.Jayanth Raghuram2019-09-021-1/+1
| | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2138 Added checks for return parameters of GetSupportedTypes function calls in InternalHstiFindAip to improve error handling. An issue was observed on Dell Poweredge R740, where the Dell PERC H740P controller UEFI driver returned InfoTypesBuffer = NULL, InfoTypesBufferCount = 0 and caused an FreePool assert. Signed-off-by: Jayanth Raghuram <Jayanth.Raghuram@Dell.com> Cc: Wei G Liu <Wei_G_Liu@Dell.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Support more file types in build cacheShi, Steven2019-09-021-20/+14
| | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1958 Current build cache does not store and restore all types file of Hii/vfr, version and dpx. This patch adds more file types to support them in build cache. Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Steven Shi <steven.shi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* UefiCpuPkg/SecCore: get AllSecPpiList after SecPlatformMain.Eric Dong2019-08-301-1/+2
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2136 SecPlatformMain is a platform hook function which let platform does some update. Some platform may adjust SecCoreData->PeiTemporaryRamBase which caused former saved AllSecPpiList variable invalid. This patch update the logic to get AllSecPpiList after SecPlatformMain. If SecPlatformMain() returns no platform-specific PPI list, then there is nothing to merge, so we don't need "AllSecPpiList" at all. Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* BaseTools: Fixed regression issue for building !x86 buildsedk2-stable201908Feng, Bob C2019-08-291-13/+16
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2134 This patch is to fix a build tool regression issue which was introduced by commit e8449e1d8e. In commit e8449e1d8e, build tool check the pcd before filter out the irrelevant library instance. The logic of evaluating the priority of the library class resolutions was not changed. Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Bob Feng <bob.c.feng@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
* BaseTools: fix an incremental build issue.Feng, Bob C2019-08-291-6/+2
| | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2137 This patch is going to fix a regression issue of incremental build which was introduced by the commit 94459080c. The changing on INF file will not trigger module rebuild. Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Steven Shi <steven.shi@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* EmulatorPkg/Win/Host: Fix SecPrint() log line endingsMichael D Kinney2019-08-271-13/+13
| | | | | | | | | | | Update use of SecPrint() to consistently use \n\r for line endings to fix formatting issues in the debug log. Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Andrew Fish <afish@apple.com> Tested-by: Tim Lewis <tim.lewis@insyde.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* EmulatorPkg/Win/Host: Fix image unload regressionMichael D Kinney2019-08-271-6/+161
| | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2104 When UEFI Applications or UEFI Drivers are unloaded, the PeCoffLoaderUnloadImageExtraAction() needs to unload the image using FreeLibrary() if the image was successfully loaded using LoadLibrrayEx(). This is a regression from the Nt32Pkg that supported unloading applications and drivers as well as loading the same application or driver multiple times. Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Andrew Fish <afish@apple.com> Tested-by: Tim Lewis <tim.lewis@insyde.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Incorrect error message for library instance not foundFeng, Bob C2019-08-234-9/+12
| | | | | | | | | | | BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2099 This is a regression issue introduced by commit e8449e. This patch is to fix this issue. Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Fix incremental build genmake issueFeng, Bob C2019-08-231-1/+2
| | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2090 This is a regression issue introduced by commit e8449e. This patch is going to fix this issue. Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Support long file path in windows for misc functionsShi, Steven2019-08-231-1/+11
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2103 Current CopyFileOnChange() and SaveFileOnChange() in BaseTools\Source\Python\Common\Misc.py don't use the dedicated long file path API to handle the file path strings and cannot support the long file path copy and save in windows. This patch enhances them to support the long file path copy and save correctly. Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Steven Shi <steven.shi@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkgAnthony PERARD2019-08-212-2/+3
| | | | | | | | | | | | | 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> Message-Id: <20190813113119.14804-36-anthony.perard@citrix.com>
* OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkgAnthony PERARD2019-08-214-2/+2
| | | | | | | | | | | 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> Message-Id: <20190813113119.14804-35-anthony.perard@citrix.com>
* OvmfPkg: Introduce XenIoPvhDxe to initialize Grant TablesAnthony PERARD2019-08-215-0/+94
| | | | | | | | | | | | | | | 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> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-34-anthony.perard@citrix.com>
* OvmfPkg: Introduce PcdXenGrantFramesAnthony PERARD2019-08-214-2/+8
| | | | | | | | | | | | 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> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-33-anthony.perard@citrix.com>
* OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConInAnthony PERARD2019-08-216-4/+58
| | | | | | | | | | | | | | | | | | | | 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 work on both PVH guest and HVM guests, even if it is rarely going to be used 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> Message-Id: <20190813113119.14804-32-anthony.perard@citrix.com>
* OvmfPkg/OvmfXen: Introduce XenTimerDxeAnthony PERARD2019-08-216-4/+577
| | | | | | | | | | | | | | | | "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> Message-Id: <20190813113119.14804-31-anthony.perard@citrix.com>
* OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequencyAnthony PERARD2019-08-211-0/+3
| | | | | | | | | | | 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> Message-Id: <20190813113119.14804-30-anthony.perard@citrix.com>
* OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVHAnthony PERARD2019-08-211-0/+6
| | | | | | | | | | | | 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> Message-Id: <20190813113119.14804-29-anthony.perard@citrix.com>
* OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLibAnthony PERARD2019-08-212-34/+2
| | | | | | | | | | 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> Message-Id: <20190813113119.14804-28-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformLib: Cache result for XenDetectedAnthony PERARD2019-08-211-4/+16
| | | | | | | | | | | | 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> Message-Id: <20190813113119.14804-27-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVHAnthony PERARD2019-08-211-0/+6
| | | | | | | | | | 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> Message-Id: <20190813113119.14804-26-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot LinuxAnthony PERARD2019-08-211-0/+16
| | | | | | | | | | | | | | | | | 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> Message-Id: <20190813113119.14804-25-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Rework memory detectionAnthony PERARD2019-08-214-22/+148
| | | | | | | | | | | | | | | | | | | | | 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 programs that have run 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> Message-Id: <20190813113119.14804-24-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercallAnthony PERARD2019-08-211-1/+45
| | | | | | | | | | | | 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. 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> Message-Id: <20190813113119.14804-23-anthony.perard@citrix.com>
* OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.hAnthony PERARD2019-08-211-0/+23
| | | | | | | | | | | 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> Message-Id: <20190813113119.14804-22-anthony.perard@citrix.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-13 12:29:20 +0000