summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/Xen: Fix various typosAntoine Coeur2020-02-1018-31/+31
| | | | | | | | | | | | | | | | Fix various typos in comments and documentation. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-61-philmd@redhat.com>
* OvmfPkg/Xen: Fix a typoPhilippe Mathieu-Daudé2020-02-101-1/+1
| | | | | | | | | | | | | | Fix a typo in a comment. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-60-philmd@redhat.com>
* OvmfPkg/Virtio: Fix few typosAntoine Coeur2020-02-106-6/+6
| | | | | | | | | | | | | Fix few typos in comments and documentation. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-59-philmd@redhat.com>
* OvmfPkg/Qemu: Fix various typosAntoine Coeur2020-02-1011-25/+25
| | | | | | | | | | | | | | | | | | | | Fix various typos in comments and documentation. When "VbeShim.asm" is modified, we have to re-run "VbeShim.sh" to update "VbeShim.h". The string modified by this patch is only used when the DEBUG macro (at the top of the file) is commented out. Since the string is not referenced, NASM eliminates it, resulting in the same byte array content in "VbeShim.h". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-58-philmd@redhat.com>
* OvmfPkg/Csm/LegacyBios: Fix a typoPhilippe Mathieu-Daudé2020-02-101-1/+1
| | | | | | | | Fix a typo in the header documentation. Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-57-philmd@redhat.com>
* OvmfPkg/Csm: Fix various typosAntoine Coeur2020-02-1021-62/+62
| | | | | | | | | | | | | | Fix various typos in documentation, comments and strings. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-56-philmd@redhat.com>
* OvmfPkg/Acpi: Fix few typosAntoine Coeur2020-02-105-8/+8
| | | | | | | | | | | | | Fix few typos in comments and documentation. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-55-philmd@redhat.com>
* OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)Laszlo Ersek2020-02-052-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the SMRAM at the default SMBASE is honored everywhere necessary, implement the actual detection. The (simple) steps are described in previous patch "OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macros". Regarding CSM_ENABLE builds: according to the discussion with Jiewen at https://edk2.groups.io/g/devel/message/48082 http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F7C9D2F@shsmsx102.ccr.corp.intel.com if the platform has SMRAM at the default SMBASE, then we have to (a) either punch a hole in the legacy E820 map as well, in LegacyBiosBuildE820() [OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c], (b) or document, or programmatically catch, the incompatibility between the "SMRAM at default SMBASE" and "CSM" features. Because CSM is out of scope for the larger "VCPU hotplug with SMM" feature, option (b) applies. Therefore, if the CSM is enabled in the OVMF build, then PlatformPei will not attempt to detect SMRAM at the default SMBASE, at all. This is approach (4) -- the most flexible one, for end-users -- from: http://mid.mail-archive.com/868dcff2-ecaa-e1c6-f018-abe7087d640c@redhat.com https://edk2.groups.io/g/devel/message/48348 Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> 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> Message-Id: <20200129214412.2361-12-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PcdCsmEnable feature flagLaszlo Ersek2020-02-055-0/+17
| | | | | | | | | | | | | | | | | | | | | In the DXE phase and later, it is possible for a module to dynamically determine whether a CSM is enabled. An example can be seen in commit 855743f71774 ("OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM", 2016-05-25). SEC and PEI phase modules cannot check the Legacy BIOS Protocol however. For their sake, introduce a new feature PCD that simply reflects the CSM_ENABLE build flag. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200129214412.2361-11-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASELaszlo Ersek2020-02-056-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During normal boot, when EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by platform BDS, the SMM IPL locks SMRAM (TSEG) through EFI_SMM_ACCESS2_PROTOCOL.Lock(). See SmmIplReadyToLockEventNotify() in "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c". During S3 resume, S3Resume2Pei locks SMRAM (TSEG) through PEI_SMM_ACCESS_PPI.Lock(), before executing the boot script. See S3ResumeExecuteBootScript() in "UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c". Those are precisely the places where the SMRAM at the default SMBASE should be locked too. Add such an action to SmramAccessLock(). Notes: - The SMRAM at the default SMBASE doesn't support the "closed and unlocked" state (and so it can't be closed without locking it, and it cannot be opened after closing it). - The SMRAM at the default SMBASE isn't (and shouldn't) be exposed with another EFI_SMRAM_DESCRIPTOR in the GetCapabilities() members of EFI_SMM_ACCESS2_PROTOCOL / PEI_SMM_ACCESS_PPI. That's because the SMRAM in question is not "general purpose"; it's only QEMU's solution to protect the initial SMI handler from the OS, when a VCPU is hot-plugged. Consequently, the state of the SMRAM at the default SMBASE is not reflected in the "OpenState" / "LockState" fields of the protocol and PPI. - An alternative to extending SmramAccessLock() would be to register an EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL notify in SmmAccess2Dxe (for locking at normal boot), and an EDKII_S3_SMM_INIT_DONE_GUID PPI notify in SmmAccessPei (for locking at S3 resume). 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-10-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default SMBASELaszlo Ersek2020-02-053-7/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When OVMF runs in a SEV guest, the initial SMM Save State Map is (1) allocated as EfiBootServicesData type memory in OvmfPkg/PlatformPei, function AmdSevInitialize(), for preventing unintended information sharing with the hypervisor; (2) decrypted in AmdSevDxe; (3) re-encrypted in OvmfPkg/Library/SmmCpuFeaturesLib, function SmmCpuFeaturesSmmRelocationComplete(), which is called by PiSmmCpuDxeSmm right after initial SMBASE relocation; (4) released to DXE at the same location. The SMRAM at the default SMBASE is a superset of the initial Save State Map. The reserved memory allocation in InitializeRamRegions(), from the previous patch, must override the allocating and freeing in (1) and (4), respectively. (Note: the decrypting and re-encrypting in (2) and (3) are unaffected.) In AmdSevInitialize(), only assert the containment of the initial Save State Map, in the larger area already allocated by InitializeRamRegions(). In SmmCpuFeaturesSmmRelocationComplete(), preserve the allocation of the initial Save State Map into OS runtime, as part of the allocation done by InitializeRamRegions(). Only assert containment. These changes only affect the normal boot path (the UEFI memory map is untouched during S3 resume). 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-9-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: reserve the SMRAM at the default SMBASE, if it existsLaszlo Ersek2020-02-051-2/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 128KB SMRAM at the default SMBASE will be used for protecting the initial SMI handler for hot-plugged VCPUs. After platform reset, the SMRAM in question is open (and looks just like RAM). When BDS signals EFI_DXE_MM_READY_TO_LOCK_PROTOCOL (and so TSEG is locked down), we're going to lock the SMRAM at the default SMBASE too. For this, we have to reserve said SMRAM area as early as possible, from components in PEI, DXE, and OS runtime. * QemuInitializeRam() currently produces a single resource descriptor HOB, for exposing the system RAM available under 1GB. This occurs during both normal boot and S3 resume identically (the latter only for the sake of CpuMpPei borrowing low RAM for the AP startup vector). But, the SMRAM at the default SMBASE falls in the middle of the current system RAM HOB. Split the HOB, and cover the SMRAM with a reserved memory HOB in the middle. CpuMpPei (via MpInitLib) skips reserved memory HOBs. * InitializeRamRegions() is responsible for producing memory allocation HOBs, carving out parts of the resource descriptor HOBs produced in QemuInitializeRam(). Allocate the above-introduced reserved memory region in full, similarly to how we treat TSEG, so that DXE and the OS avoid the locked SMRAM (black hole) in this area. (Note that these allocations only occur on the normal boot path, as they matter for the UEFI memory map, which cannot be changed during S3 resume.) 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-8-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: assert there's no permanent PEI RAM at default SMBASELaszlo Ersek2020-02-051-0/+10
| | | | | | | | | | | | | | | | | | | | | | | The permanent PEI RAM that is published on the normal boot path starts strictly above MEMFD_BASE_ADDRESS (8 MB -- see the FDF files), regardless of whether PEI decompression will be necessary on S3 resume due to SMM_REQUIRE. Therefore the normal boot permanent PEI RAM never overlaps with the SMRAM at the default SMBASE (192 KB). The S3 resume permanent PEI RAM is strictly above the normal boot one. Therefore the no-overlap statement holds true on the S3 resume path as well. Assert the no-overlap condition commonly for both boot paths in PublishPeiMemory(). 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-7-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton)Laszlo Ersek2020-02-054-0/+27
| | | | | | | | | | | | | | | | | 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-052-12/+24
| | | | | | | | | | | | | | 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/IndustryStandard: add MCH_DEFAULT_SMBASE* register macrosLaszlo Ersek2020-02-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Intel datasheet 316966-002 (the "q35 spec"), Table 5-1 "DRAM Controller Register Address Map (D0:F0)" leaves the byte register at config space offset 0x9C unused. On QEMU's Q35 board, for detecting the "SMRAM at default SMBASE" feature, firmware is expected to write MCH_DEFAULT_SMBASE_QUERY (0xFF) to offset MCH_DEFAULT_SMBASE_CTL (0x9C), and read back the register. If the value is MCH_DEFAULT_SMBASE_IN_RAM (0x01), then the feature is available, and the range mentioned below is open (accessible to code running outside of SMM). Then, once firmware writes MCH_DEFAULT_SMBASE_LCK (0x02) to the register, the MCH_DEFAULT_SMBASE_SIZE (128KB) range at 0x3_0000 (SMM_DEFAULT_SMBASE) gets closed and locked down, and the register becomes read-only. The area is reopened, and the register becomes read/write, at platform reset. Add the above-listed macros to "Q35MchIch9.h". (There are some other unused offsets in Table 5-1; for example we had scavenged 0x50 for implementing the extended TSEG feature. 0x9C is the first byte-wide register standing in isolation after 0x50.) 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-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro defsLaszlo Ersek2020-02-051-50/+50
| | | | | | | | | | | | | | | | | In a subsequent patch, we'll introduce new DRAM controller macros in "Q35MchIch9.h". Their names are too long for the currently available vertical whitespace, so increase the latter first. There is no functional change in this patch ("git show -b" displays nothing). 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-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PcdQ35SmramAtDefaultSmbaseLaszlo Ersek2020-02-054-0/+9
| | | | | | | | | | | | | | | | | | | | | For supporting VCPU hotplug with SMM enabled/required, QEMU offers the (dynamically detectable) feature called "SMRAM at default SMBASE". When the feature is enabled, the firmware can lock down the 128 KB range starting at the default SMBASE; that is, the [0x3_0000, 0x4_FFFF] interval. The goal is to shield the very first SMI handler of the hotplugged VCPU from OS influence. Multiple modules in OVMF will have to inter-operate for locking down this range. Introduce a dynamic PCD that will reflect the feature (to be negotiated by PlatformPei), for coordination between drivers. 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-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplugLaszlo Ersek2020-01-295-28/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/IndustryStandard: define macros for QEMU's CPU hotplug registersLaszlo Ersek2020-01-293-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | In v1.5.0, QEMU's "pc" (i440fx) board gained a "CPU present bitmap" register block. In v2.0.0, this was extended to the "q35" board. In v2.7.0, a new (read/write) register interface was laid over the "CPU present bitmap", with an option for the guest to switch the register block to the new (a.k.a. modern) interface. Both interfaces are documented in "docs/specs/acpi_cpu_hotplug.txt" in the QEMU tree. Add macros for a minimal subset of the modern interface, just so we can count the possible CPUs (as opposed to boot CPUs) in a later patch in this series. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20191022221554.14963-3-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/OvmfXen.dsc: remove PcdCpu* dynamic defaultsLaszlo Ersek2020-01-291-4/+0
| | | | | | | | | | | | | | | | | | | PcdCpuMaxLogicalProcessorNumber and PcdCpuApInitTimeOutInMicroSeconds are only referenced in "OvmfPkg/PlatformPei/PlatformPei.inf", and OvmfXen does not include that module. Remove the unnecessary dynamic PCD defaults from "OvmfXen.dsc". 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> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Message-Id: <20191022221554.14963-2-lersek@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: remove EnterS3WithImmediateWake () from ResetSystemLibArd Biesheuvel2020-01-101-18/+0
| | | | | | | | EnterS3WithImmediateWake () no longer has any callers, so remove it from ResetSystemLib. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: use HII type PCDs for TPM2 config related variablesArd Biesheuvel2020-01-093-0/+18
| | | | | | | | | | | | | | | The HII pages that are part of Tcg2ConfigDxe expect the following PCDs to be of dynamic HII type, so declare them as such. gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev Currently, the TPM2 ACPI table is not produced, since we do not incorporate the Tcg2Smm module, which implements the SMI based physical presence interface exposed to the OS. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: reorganize TPM2 support in DSC/FDF filesArd Biesheuvel2020-01-096-9/+27
| | | | | | | | Put the TPM2 related DXE modules together in the DSC, and add a TPM2 support header comment while at it. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg DSC: Update tool chain name to CLANGPDBLiming Gao2019-11-153-9/+9
| | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2341 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Disable variable runtime cacheMichael Kubacki2019-11-053-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Sets gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache to FALSE in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc, and OvmfPkgX64.dsc so that when SMM_REQUIRE is TRUE, the SMM variable driver will not use the runtime variable cache. This is done for OvmfPkg because it currently depends upon a SMM variable GetVariable ()implementation as a simple method to exercise the SMM driver stack. This allows the following commands to be used for variables such as Boot####, BootOrder, and BootNext to test SMM timing and stability differences on the BSP (e.g. CPU#0) vs an AP (e.g. CPU#1). # taskset -c 0 efibootmgr # taskset -c 1 efibootmgr Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Enable CLANG9 tool chainLiming Gao2019-10-243-3/+9
| | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603 1. Apply CLANG9 Linker option. 2. Exclude -mno-mmx -mno-sse compiler option for CLANG9 These two options will cause CLANG Linker crush. Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUEPeter Jones2019-10-228-38/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some tests check if it's defined or not. Additionally, in UefiPayloadPkg as well as some other trees, we define it as FALSE in the .dsc file. This patch changes all of the Ovmf platforms to explicitly define it as FALSE by default, and changes all of the checks to test if the value is TRUE. Signed-off-by: Peter Jones <pjones@redhat.com> Message-Id: <20190920184507.909884-1-pjones@redhat.com> [lersek@redhat.com: drop Contributed-under line, per TianoCore BZ#1373] [lersek@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"] Cc: Andrew Fish <afish@apple.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Peter Jones <pjones@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformBootManagerLib: Don't update progress if Pcd is 0Pete Batard2019-10-161-3/+12
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266 Independently of how we decide to address other aspects of the regression introduced with commit 2de1f611be06ded3a59726a4052a9039be7d459b, it doesn't make much sense to call for a progress update if PcdPlatformBootTimeOut is zero. PcdPlatformBootTimeOut 0, which is the cause of the bug (division by zero) should be considered to indicate that a platform is not interested in displaying a progress report, so we alter PlatformBootManagerWaitCallback to behave that way. We also change one variable name to make the code more explicit. Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20191014150311.16740-2-pete@akeo.ie>
* OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functionsLaszlo Ersek2019-10-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the following call tree: PlatformInit () mInstalledPackages = HiiAddPackages () GopInstalled () PopulateForm (PackageList = mInstalledPackages) CreateResolutionOptions (PackageList) HiiSetString (PackageList HiiUpdateForm (PackageList) PlatformDxe passes around an EFI_HII_HANDLE that (a) originates from HiiAddPackages() and (b) is ultimately passed to HiiSetString() and HiiUpdateForm(). The intermediate functions PopulateForm() and CreateResolutionOptions() however take that parameter as an (EFI_HII_HANDLE*). There is no bug in practice (because the affected functions never try to de-reference the "PackageList" parameter, they just pass it on), but the function prototypes are semantically wrong. Fix that. This could remain hidden so long because pointer-to-VOID silently converts to/from any pointer-to-object type, and the UEFI spec mandates that EFI_HII_HANDLE be a typedef to (VOID*). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> 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/VirtioNetDxe: fix SignalEvent() callLaszlo Ersek2019-10-091-1/+1
| | | | | | | | | | | | | | | | The SignalEvent() boot service takes an EFI_EVENT, not an (EFI_EVENT*). Fix the call in the notification function of "EFI_SIMPLE_NETWORK_PROTOCOL.WaitForPacket". This is an actual bug. The reason it's never been triggered is likely that the "SNP.WaitForPacket" event is rarely waited for by applications -- edk2 itself has zero instances of that, for example. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> 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/XenBusDxe: fix UninstallMultipleProtocolInterfaces() callLaszlo Ersek2019-10-091-1/+1
| | | | | | | | | | | | | | | | | | | Unlike the InstallMultipleProtocolInterfaces() boot service, which takes an (EFI_HANDLE*) as first parameter, the UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as first parameter. This is an actual bug. It must have remained hidden until now because it's on an error path. Fix the UninstallMultipleProtocolInterfaces() call. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg: strip trailing whitespaceLeif Lindholm2019-10-0427-301/+301
| | | | | | | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@arm.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.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>
* 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-212-0/+223
| | | | | | | | | | | 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-214-0/+93
| | | | | | | | | | | | | | | 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-215-4/+576
| | | | | | | | | | | | | | | | "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>
* OvmfPkg/XenPlatformPei: Introduce XenPvhDetectedAnthony PERARD2019-08-212-0/+18
| | | | | | | | | | 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> Message-Id: <20190813113119.14804-21-anthony.perard@citrix.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-21 03:59:33 +0000