summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/BhyveX64.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-1/+4
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-12-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfXen.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-11-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkgX64.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-10-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkgIa32X64.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-9-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkgIa32.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-8-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add VariablePolicy engine to OvmfPkg platformBret Barkelew2020-11-174-0/+19
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2522 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Bret Barkelew <brbarkel@microsoft.com> Signed-off-by: Bret Barkelew <brbarkel@microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Bhyve: fix build breakage after SEV-ES changesRebecca Cran2020-11-132-2/+3
| | | | | | | | | | Consume the SEV-ES-independent reset vector restored in the previous patch. Use the Null instance of VmgExitLib. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201112053153.22038-3-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Bhyve: detach ResetVector from before the SEV-ES changesRebecca Cran2020-11-133-0/+255
| | | | | | | | | | | | Commits 6995a1b79bab, 8a2732186a53 and 30937f2f98c4 modified all four regular files under "OvmfPkg/ResetVector" with SEV-ES dependencies. These are not relevant for Bhyve. Detach the pre-SEV-ES version of ResetVector for Bhyve. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201112053153.22038-2-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg, OvmfPkg: Disable interrupts when using the GHCBTom Lendacky2020-11-103-8/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The QemuFlashPtrWrite() flash services runtime uses the GHCB and VmgExit() directly to perform the flash write when running as an SEV-ES guest. If an interrupt arrives between VmgInit() and VmgExit(), the Dr7 read in the interrupt handler will generate a #VC, which can overwrite information in the GHCB that QemuFlashPtrWrite() has set. This has been seen with the timer interrupt firing and the CpuExceptionHandlerLib library code, UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ Xcode5ExceptionHandlerAsm.nasm and ExceptionHandlerAsm.nasm reading the Dr7 register while QemuFlashPtrWrite() is using the GHCB. In general, it is necessary to protect the GHCB whenever it is used, not just in QemuFlashPtrWrite(). Disable interrupts around the usage of the GHCB by modifying the VmgInit() and VmgDone() interfaces: - VmgInit() will take an extra parameter that is a pointer to a BOOLEAN that will hold the interrupt state at the time of invocation. VmgInit() will get and save this interrupt state before updating the GHCB. - VmgDone() will take an extra parameter that is used to indicate whether interrupts are to be (re)enabled. Before exiting, VmgDone() will enable interrupts if that is requested. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <c326a4fd78253f784b42eb317589176cf7d8592a.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Fix erase blocks for SEV-ESTom Lendacky2020-11-101-2/+2
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The original SEV-ES support missed updating the QemuFlashEraseBlock() function to successfully erase blocks. Update QemuFlashEraseBlock() to call the QemuFlashPtrWrite() to be able to successfully perform the commands under SEV-ES. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <309c5317a3107bd0e650be20731842a2e1d4b59a.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Set the SwScratch valid bitTom Lendacky2020-11-101-0/+1
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bit for the scratch area field (SwScratch). Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <cc8c8449740d2be0b287e6c69d48bf6cb067c7d8.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Set the SwScratch valid bit for MMIO eventsTom Lendacky2020-11-101-0/+5
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bit for the scratch area field (SwScratch). Fixes: c45f678a1ea2080344e125dc55b14e4b9f98483d Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <45ccb63c2dadd834e2c47bf10c9e59c6766d7eb6.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Set the SwScratch valid bit for IOIO eventsTom Lendacky2020-11-101-0/+1
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bit for the scratch area field (SwScratch). Fixes: 0020157a9825e5f5784ff014044f11c0558c92fe Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <f817d034cea37fa78e00e86f61c3445f1208226d.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Set the SW exit fields when performing VMGEXITTom Lendacky2020-11-101-0/+4
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bits for the software exit information fields when performing a VMGEXIT (SwExitCode, SwExitInfo1, SwExitInfo2). Fixes: 61bacc0fa16fd6f595a2c4222425cb6286e19977 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <986e157c13bf33e529b1d16ab1b52e99a74a734f.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Implement new VmgExitLib interfacesTom Lendacky2020-11-102-87/+85
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The VmgExitLib library added two new interfaces, VmgSetOffsetValid() and VmgIsOffsetValid(), that must now be implemented in the OvmfPkg version of the library. Implement VmgSetOffsetValid() and VmgIsOffsetValid() and update existing code, that is directly accessing ValidBitmap, to use the new interfaces. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <939e9dc375e6085bc67942fe9a00ecd4c6b77ecf.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg: enable HttpDynamicCommandVladimir Olovyannikov2020-10-018-0/+20
| | | | | | | | | | | Enable HttpDynamicCommand (Shell command "http") for OvmfPkg platforms. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2857 Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Message-Id: <20200722205434.4348-3-vladimir.olovyannikov@broadcom.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: remove groups.io corruption from Author meta-datum]
* OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwardingLaszlo Ersek2020-09-221-9/+15
| | | | | | | | | | | | | | | | | | | | | | | In QEMU commit range 4abf70a661a5..69699f3055a5 (later fixed up in QEMU commit 4318432ccd3f), Phil implemented a QEMU facility for exposing the host-side TLS cipher suite configuration to OVMF. The purpose is to control the permitted ciphers in the guest's UEFI HTTPS boot. This complements the forwarding of the host-side crypto policy from the host to the guest -- the other facet was the set of CA certificates (for which p11-kit patches had been upstreamed, on the host side). Mention the new command line options in "OvmfPkg/README". Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200922091827.12617-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: Add RngLib based on TimerLib for CryptoMatthew Carlson2020-09-185-0/+5
| | | | | | | | | | | | | | | | | | | | Updates the DSC's for Ovmf based platforms to add a RngLib that uses the TimerLib. This is due to a later change that adds TimerLib as a dependency for OpenSSL. The TimerLib based RngLib mimics the behavior of OpenSSL previously and it is recommended to switch to a better source of entropy than the system's performance counter. Ref: https://github.com/tianocore/edk2/pull/845 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
* OvmfPkg: drop redundant VendorID check in VirtioMmioDeviceLibLeif Lindholm2020-09-171-15/+0
| | | | | | | | | | | | | | | | | | | | | | There is a DEBUG warning printout in VirtioMmioDeviceLib if the current device's VendorID does not match the traditional 16-bit Red Hat PCIe vendor ID used with virtio-pci. The virtio-mmio vendor ID is 32-bit and has no connection to the PCIe registry. Most specifically, this causes a bunch of noise when booting an AArch64 QEMU platform, since QEMU's virtio-mmio implementation used 'QEMU' as the vendor ID: VirtioMmioInit: Warning: The VendorId (0x554D4551) does not match the VirtIo VendorId (0x1AF4). Drop the warning message. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcastLaszlo Ersek2020-08-271-6/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick succession -- it means a series of "device_add" QEMU monitor commands, back-to-back. If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then: - the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the SMI pending for the new CPU -- at that time, the new CPU doesn't even exist yet, - OVMF will find the new CPU however (in the CPU hotplug register block), in QemuCpuhpCollectApicIds(). As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI), the new CPU instead boots straight into the post-RSM (normal mode) "pen", skipping its initial SMI handler. The CPU halts nicely in the pen, but its SMBASE is never relocated, and the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck in the following loop: // // Wait until the hot-added CPU is just about to execute RSM. // while (Context->AboutToLeaveSmm == 0) { CpuPause (); } because the new CPU's initial SMI handler never sets the flag to nonzero. Fix this by sending a directed SMI to the new CPU just before sending it the INIT-SIPI-SIPI. The various scenarios are documented in the code -- the cases affected by the patch are documented under point (2). Note that this is not considered a security patch, as for a malicious guest OS, the issue is not exploitable -- the symptom is a hang on the BSP, in the above-noted loop in SmbaseRelocate(). Instead, the patch fixes behavior for a benign guest OS. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: 51a6fb41181529e4b50ea13377425bda6bb69ba6 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200826222129.25798-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just before SMI broadcastLaszlo Ersek2020-08-271-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick succession -- it means a series of "device_add" QEMU monitor commands, back-to-back. If a "device_add" occurs *just before* ACPI raises the broadcast SMI, then: - OVMF processes the hot-added CPU well. - However, QEMU's post-SMI ACPI loop -- which clears the pending events for the hot-added CPUs that were collected before raising the SMI -- is unaware of the stray CPU. Thus, the pending event is not cleared for it. As a result of the stuck event, at the next hot-plug, OVMF tries to re-add (relocate for the 2nd time) the already-known CPU. At that time, the AP is already in the normal edk2 SMM busy-wait however, so it doesn't respond to the exchange that the BSP intends to do in SmbaseRelocate(). Thus the VM gets stuck in SMM. (Because of the above symptom, this is not considered a security patch; it doesn't seem exploitable by a malicious guest OS.) In CpuHotplugMmi(), skip the supposedly hot-added CPU if it's already known. The post-SMI ACPI loop will clear the pending event for it this time. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: bc498ac4ca7590479cfd91ad1bb8a36286b0dc21 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200826222129.25798-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/Bhyve: rename files to remove 'Pkg' infixRebecca Cran2020-08-243-2/+2
| | | | | | | | | | | | | | OvmfPkg is the package, so while there are files to build bhyve separately, they shouldn't have 'Pkg' in the name. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Peter Grehan <grehan@freebsd.org> Message-Id: <20200818021035.6479-1-rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/SmmControl2Dxe: negotiate ICH9_LPC_SMI_F_CPU_HOTPLUGLaszlo Ersek2020-08-242-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ICH9_LPC_SMI_F_BROADCAST and ICH9_LPC_SMI_F_CPU_HOTPLUG feature flags cause QEMU to behave as follows: BROADCAST CPU_HOTPLUG use case / behavior --------- ----------- ------------------------------------------------ clear clear OVMF built without SMM_REQUIRE; or very old OVMF (from before commit a316d7ac91d3 / 2017-02-07). QEMU permits CPU hotplug operations, and does not cause the OS to inject an SMI upon hotplug. Firmware is not expected to be aware of hotplug events. clear set Invalid feature set; QEMU rejects the feature negotiation. set clear OVMF after a316d7ac91d3 / 2017-02-07, built with SMM_REQUIRE, but no support for CPU hotplug. QEMU gracefully refuses hotplug operations. set set OVMF after a316d7ac91d3 / 2017-02-07, built with SMM_REQUIRE, and supporting CPU hotplug. QEMU permits CPU hotplug operations, and causes the OS to inject an SMI upon hotplug. Firmware is expected to deal with hotplug events. Negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG -- but only if SEV is disabled, as OvmfPkg/CpuHotplugSmm can't deal with SEV yet. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Liran Alon <liran.alon@oracle.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200714184305.9814-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: Fix spelling mistake for occurredMichael D Kinney2020-08-193-3/+3
| | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2361 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Guomin Jiang <guomin.jiang@intel.com>
* OvmfPkg/OvmfPkg.ci.yaml: Add configuration for Ecc checkShenglei Zhang2020-08-171-0/+12
| | | | | | | | | | | | Add configuration ExceptionList and IgnoreFiles for package config files. So users can rely on this to ignore some Ecc issues. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* OvmfPkg: Move the GHCB allocations into reserved memoryTom Lendacky2020-08-171-1/+3
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 After having transitioned from UEFI to the OS, the OS will need to boot the APs. For an SEV-ES guest, the APs will have been parked by UEFI using GHCB pages allocated by UEFI. The hypervisor will write to the GHCB SW_EXITINFO2 field of the GHCB when the AP is booted. As a result, the GHCB pages must be marked reserved so that the OS does not attempt to use them and experience memory corruption because of the hypervisor write. Change the GHCB allocation from the default boot services memory to reserved memory. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vectorTom Lendacky2020-08-172-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 A hypervisor is not allowed to update an SEV-ES guest's register state, so when booting an SEV-ES guest AP, the hypervisor is not allowed to set the RIP to the guest requested value. Instead an SEV-ES AP must be re-directed from within the guest to the actual requested staring location as specified in the INIT-SIPI-SIPI sequence. Use the SEV-ES work area for the reset vector code that contains support to jump to the desired RIP location after having been started. This is required for only the very first AP reset. This new OVMF source file, ResetVectorVtf0.asm, is used in place of the original file through the use of the include path order set in OvmfPkg/ResetVector/ResetVector.inf under "[BuildOptions]". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with SEV-ESTom Lendacky2020-08-175-3/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 The flash detection routine will attempt to determine how the flash device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and the flash device behaves as a ROM device (meaning it is marked read-only by the hypervisor), this check may result in an infinite nested page fault because of the attempted write. Since the instruction cannot be emulated when SEV-ES is enabled, the RIP is never advanced, resulting in repeated nested page faults. When SEV-ES is enabled, exit the flash detection early and assume that the FD behaves as Flash. This will result in QemuFlashWrite() being called to store EFI variables, which will also result in an infinite nested page fault when the write is performed. In this case, update QemuFlashWrite() to use the VMGEXIT MMIO write support to have the hypervisor perform the write without having to emulate the instruction. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Sec: Enable cache early to speed up bootingTom Lendacky2020-08-171-0/+7
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Currently, the OVMF code relies on the hypervisor to enable the cache support on the processor in order to improve the boot speed. However, with SEV-ES, the hypervisor is not allowed to change the CR0 register to enable caching. Update the OVMF Sec support to enable caching in order to improve the boot speed when running as an SEV-ES guest. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Sec: Add #VC exception handling for Sec phaseTom Lendacky2020-08-172-13/+173
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 An SEV-ES guest will generate a #VC exception when it encounters a non-automatic exit (NAE) event. It is expected that the #VC exception handler will communicate with the hypervisor using the GHCB to handle the NAE event. NAE events can occur during the Sec phase, so initialize exception handling early in the OVMF Sec support. Before establishing the exception handling, validate that the supported version of the SEV-ES protocol in OVMF is supported by the hypervisor. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/ResetVector: Add support for a 32-bit SEV checkTom Lendacky2020-08-173-3/+277
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 During BSP startup, the reset vector code will issue a CPUID instruction while in 32-bit mode. When running as an SEV-ES guest, this will trigger a #VC exception. Add exception handling support to the early reset vector code to catch these exceptions. Also, since the guest is in 32-bit mode at this point, writes to the GHCB will be encrypted and thus not able to be read by the hypervisor, so use the GHCB CPUID request/response protocol to obtain the requested CPUID function values and provide these to the guest. The exception handling support is active during the SEV check and uses the OVMF temporary RAM space for a stack. After the SEV check is complete, the exception handling support is removed and the stack pointer cleared. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformPei: Reserve SEV-ES work area if S3 is supportedTom Lendacky2020-08-172-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Protect the SEV-ES work area memory used by an SEV-ES guest. Regarding the lifecycle of the SEV-ES memory area: PcdSevEsWorkArea (a) when and how it is initialized after first boot of the VM If SEV-ES is enabled, the SEV-ES area is initialized during the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm]. (b) how it is protected from memory allocations during DXE If SEV-ES is enabled, then InitializeRamRegions() [OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with either an AcpiNVS (S3 enabled) or BootServicesData (S3 disabled) memory allocation HOB, in PEI. (c) how it is protected from the OS If S3 is enabled, then (b) reserves it from the OS too. If S3 is disabled, then the range needs no protection. (d) how it is accessed on the S3 resume path It is rewritten same as in (a), which is fine because (b) reserved it. (e) how it is accessed on the warm reset path It is rewritten same as in (a). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Reserve a page in memory for the SEV-ES usageTom Lendacky2020-08-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Reserve a fixed area of memory for SEV-ES use and set a fixed PCD, PcdSevEsWorkAreaBase, to this value. This area will be used by SEV-ES support for two purposes: 1. Communicating the SEV-ES status during BSP boot to SEC: Using a byte of memory from the page, the BSP reset vector code can communicate the SEV-ES status to SEC for use before exception handling can be enabled in SEC. After SEC, this field is no longer valid and the standard way of determine if SEV-ES is active should be used. 2. Establishing an area of memory for AP boot support: A hypervisor is not allowed to update an SEV-ES guest's register state, so when booting an SEV-ES guest AP, the hypervisor is not allowed to set the RIP to the guest requested value. Instead an SEV-ES AP must be re-directed from within the guest to the actual requested staring location as specified in the INIT-SIPI-SIPI sequence. Use this memory for reset vector code that can be programmed to have the AP jump to the desired RIP location after starting the AP. This is required for only the very first AP reset. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformPei: Move early GDT into ram when SEV-ES is enabledTom Lendacky2020-08-171-0/+18
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 The SEV support will clear the C-bit from non-RAM areas. The early GDT lives in a non-RAM area, so when an exception occurs (like a #VC) the GDT will be read as un-encrypted even though it is encrypted. This will result in a failure to be able to handle the exception. Move the GDT into RAM so it can be accessed without error when running as an SEV-ES guest. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Create GHCB pages for use during Pei and Dxe phaseTom Lendacky2020-08-175-1/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Allocate memory for the GHCB pages and the per-CPU variable pages during SEV initialization for use during Pei and Dxe phases. The GHCB page(s) must be shared pages, so clear the encryption mask from the current page table entries. Upon successful allocation, set the GHCB PCDs (PcdGhcbBase and PcdGhcbSize). The per-CPU variable page needs to be unique per AP. Using the page after the GHCB ensures that it is unique per AP. Only the GHCB page is marked as shared, keeping the per-CPU variable page encyrpted. The same logic is used in DXE using CreateIdentityMappingPageTables() before switching to the DXE pagetables. The GHCB pages (one per vCPU) will be used by the PEI and DXE #VC exception handlers. The #VC exception handler will fill in the necessary fields of the GHCB and exit to the hypervisor using the VMGEXIT instruction. The hypervisor then accesses the GHCB associated with the vCPU in order to perform the requested function. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformPei: Reserve GHCB-related areas if S3 is supportedTom Lendacky2020-08-172-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Protect the memory used by an SEV-ES guest when S3 is supported. This includes the page table used to break down the 2MB page that contains the GHCB so that it can be marked un-encrypted, as well as the GHCB area. Regarding the lifecycle of the GHCB-related memory areas: PcdOvmfSecGhcbPageTableBase PcdOvmfSecGhcbBase (a) when and how it is initialized after first boot of the VM If SEV-ES is enabled, the GHCB-related areas are initialized during the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm]. (b) how it is protected from memory allocations during DXE If S3 and SEV-ES are enabled, then InitializeRamRegions() [OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with an AcpiNVS memory allocation HOB, in PEI. If S3 is disabled, then these ranges are not protected. DXE's own page tables are first built while still in PEI (see HandOffToDxeCore() [MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c]). Those tables are located in permanent PEI memory. After CR3 is switched over to them (which occurs before jumping to the DXE core entry point), we don't have to preserve PcdOvmfSecGhcbPageTableBase. PEI switches to GHCB pages in permanent PEI memory and DXE will use these PEI GHCB pages, so we don't have to preserve PcdOvmfSecGhcbBase. (c) how it is protected from the OS If S3 is enabled, then (b) reserves it from the OS too. If S3 is disabled, then the range needs no protection. (d) how it is accessed on the S3 resume path It is rewritten same as in (a), which is fine because (b) reserved it. (e) how it is accessed on the warm reset path It is rewritten same as in (a). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Create a GHCB page for use during Sec phaseTom Lendacky2020-08-175-0/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 A GHCB page is needed during the Sec phase, so this new page must be created. Since the #VC exception handler routines assume that a per-CPU variable area is immediately after the GHCB, this per-CPU variable area must also be created. Since the GHCB must be marked as an un-encrypted, or shared, page, an additional pagetable page is required to break down the 2MB region where the GHCB page lives into 4K pagetable entries. Create a new entry in the OVMF memory layout for the new page table page and for the SEC GHCB and per-CPU variable pages. After breaking down the 2MB page, update the GHCB page table entry to remove the encryption mask. The GHCB page will be used by the SEC #VC exception handler. The #VC exception handler will fill in the necessary fields of the GHCB and exit to the hypervisor using the VMGEXIT instruction. The hypervisor then accesses the GHCB in order to perform the requested function. Four new fixed PCDs are needed to support the SEC GHCB page: - PcdOvmfSecGhcbBase UINT32 value that is the base address of the GHCB used during the SEC phase. - PcdOvmfSecGhcbSize UINT32 value that is the size, in bytes, of the GHCB area used during the SEC phase. - PcdOvmfSecGhcbPageTableBase UINT32 value that is address of a page table page used to break down the 2MB page into 512 4K pages. - PcdOvmfSecGhcbPageTableSize UINT32 value that is the size, in bytes, of the page table page. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add support to perform SEV-ES initializationTom Lendacky2020-08-175-0/+36
| | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 When SEV-ES is enabled, then SEV is also enabled. Add support to the SEV initialization function to also check for SEV-ES being enabled, and if enabled, set the SEV-ES enabled PCD (PcdSevEsIsEnabled). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/MemEncryptSevLib: Add an SEV-ES guest indicator functionTom Lendacky2020-08-172-14/+47
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Create a function that can be used to determine if the VM is running as an SEV-ES guest. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for DR7 Read/Write NAE eventsTom Lendacky2020-08-171-0/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a DR7 read or write intercept generates a #VC exception. The #VC handler must provide special support to the guest for this. On a DR7 write, the #VC handler must cache the value and issue a VMGEXIT to notify the hypervisor of the write. However, the #VC handler must not actually set the value of the DR7 register. On a DR7 read, the #VC handler must return the cached value of the DR7 register to the guest. VMGEXIT is not invoked for a DR7 register read. The caching of the DR7 values will make use of the per-CPU data pages that are allocated along with the GHCB pages. The per-CPU page for a vCPU is the page that immediately follows the vCPU's GHCB page. Since each GHCB page is unique for a vCPU, the page that follows becomes unique for that vCPU. The SEC phase will reserves an area of memory for a single GHCB and per-CPU page for use by the BSP. After transitioning to the PEI phase, new GHCB and per-CPU pages are allocated for the BSP and all APs. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for MWAIT/MWAITX NAE eventsTom Lendacky2020-08-171-0/+36
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a MWAIT/MWAITX intercept generates a #VC exception. VMGEXIT must be used to allow the hypervisor to handle this intercept. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for MONITOR/MONITORX NAE eventsTom Lendacky2020-08-171-0/+38
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a MONITOR/MONITORX intercept generates a #VC exception. VMGEXIT must be used to allow the hypervisor to handle this intercept. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for RDTSCP NAE eventsTom Lendacky2020-08-171-0/+47
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a RDTSCP intercept generates a #VC exception. VMGEXIT must be used to allow the hypervisor to handle this intercept. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for VMMCALL NAE eventsTom Lendacky2020-08-171-0/+48
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a VMMCALL intercept generates a #VC exception. VMGEXIT must be used to allow the hypervisor to handle this intercept. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for INVD NAE eventsTom Lendacky2020-08-171-0/+29
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a INVD intercept generates a #VC exception. VMGEXIT must be used to allow the hypervisor to handle this intercept. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for RDPMC NAE eventsTom Lendacky2020-08-171-0/+46
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a RDPMC intercept generates a #VC exception. VMGEXIT must be used to allow the hypervisor to handle this intercept. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for RDTSC NAE eventsTom Lendacky2020-08-171-0/+43
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a RDTSC intercept generates a #VC exception. VMGEXIT must be used to allow the hypervisor to handle this intercept. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for WBINVD NAE eventsTom Lendacky2020-08-171-0/+29
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a WBINVD intercept generates a #VC exception. VMGEXIT must be used to allow the hypervisor to handle this intercept. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for NPF NAE events (MMIO)Tom Lendacky2020-08-171-0/+488
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a NPF intercept for an NPT entry with a reserved bit set generates a #VC exception. This condition is assumed to be an MMIO access. VMGEXIT must be used to allow the hypervisor to handle this intercept. Add support to construct the required GHCB values to support a NPF NAE event for MMIO. Parse the instruction that generated the #VC exception, setting the required register values in the GHCB and creating the proper SW_EXIT_INFO1, SW_EXITINFO2 and SW_SCRATCH values in the GHCB. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Add support for MSR_PROT NAE eventsTom Lendacky2020-08-171-0/+65
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Under SEV-ES, a MSR_PROT intercept generates a #VC exception. VMGEXIT must be used to allow the hypervisor to handle this intercept. Add support to construct the required GHCB values to support an MSR_PROT NAE event. Parse the instruction that generated the #VC exception to determine whether it is RDMSR or WRMSR, setting the required register register values in the GHCB and creating the proper SW_EXIT_INFO1 value in the GHCB. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-22 01:15:46 +0000