summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgIa32X64.dsc
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: Add MicrocodeLib in DSC files.Ray Ni2021-04-091-0/+1
| | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3303 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Consume MdeLibs.dsc.inc for RegisterFilterLibDandan Bi2021-03-311-1/+4
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246 MdeLibs.dsc.inc was added for some basic/default library instances provided by MdePkg and RegisterFilterLibNull Library was also added into it as the first version of MdeLibs.dsc.inc. So update platform dsc to consume MdeLibs.dsc.inc for RegisterFilterLibNull which will be consumed by IoLib and BaseLib. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: strip build paths in release buildsRoss Burton2021-03-241-0/+1
| | | | | | | | | | | | GenFw will embed a NB10 section which contains the path to the input file, which means the output files have build paths embedded in them. To reduce information leakage and ensure reproducible builds, pass --zero in release builds to remove this information. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3256 Signed-off-by: Ross Burton <ross.burton@arm.com> Message-Id: <20210324115819.605436-1-ross.burton@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: resolve MmUnblockMemoryLib (mainly for VariableSmmRuntimeDxe)Kun Qin2021-03-051-0/+3
| | | | | | | | | | | | | | | This change added NULL MmUnblockMemoryLib instance in dsc files of OvmfPkg to pass CI build. When SMM_REQUIRE flag is set, the library interface is consumed by VariableSmmRuntimeDxe to better support variable runtime cache feature. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Kun Qin <kun.q@outlook.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <MWHPR06MB31028DFAB7AE46E32E5F9F86F3969@MWHPR06MB3102.namprd06.prod.outlook.com>
* OvmfPkg: Introduce PciHostBridgeUtilityLib classJiahui Cen via groups.io2021-01-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | Introduce a new PciHostBridgeUtilityLib class to share duplicate code between OvmfPkg and ArmVirtPkg. Extract function PciHostBridgeUtilityResourceConflict from PciHostBridgeResourceConflict in OvmfPkg/PciHostBridgeLib. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3059 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210119011302.10908-2-cenjiahui@huawei.com>
* OvmfPkg: disable list length checks in NOOPT and DEBUG buildsLaszlo Ersek2021-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In NOOPT and DEBUG builds, if "PcdMaximumLinkedListLength" is nonzero, then several LIST_ENTRY *node* APIs in BaseLib compare the *full* list length against the PCD. This turns the time complexity of node-level APIs from constant to linear, and that of full-list manipulations from linear to quadratic. As an example, consider the EFI_SHELL_FILE_INFO list, which is a data structure that's widely used in the UEFI shell. I randomly extracted 5000 files from "/usr/include" on my laptop, spanning 1095 subdirectories out of 1538, and then ran "DIR -R" in the UEFI shell on this tree. These are the wall-clock times: PcdMaximumLinkedListLength PcdMaximumLinkedListLength =1,000,000 =0 -------------------------- --------------------------- FAT 4 min 31 s 18 s virtio-fs 5 min 13 s 1 min 33 s Checking list lengths against an arbitrary maximum (default: 1,000,000) seems useless even in NOOPT and DEBUG builds, while the cost is significant; so set the PCD to 0. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3152 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20210113085453.10168-10-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: raise PcdShellFileOperationSize to 128KBLaszlo Ersek2021-01-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some UEFI shell commands read and write files in chunks. The chunk size is given by "PcdShellFileOperationSize", whose default in "ShellPkg/ShellPkg.dec" is 4KB (0x1000). The virtio-fs daemon of QEMU advertizes a 128KB maximum buffer size by default, for the FUSE_WRITE operation. By raising PcdShellFileOperationSize 32-fold, the number of FUSE write requests shrinks proportionately, when writing large files. And when a Virtio Filesystem is not used, a 128KB chunk size is still not particularly wasteful. Some ad-hoc measurements on my laptop, using OVMF: - The time it takes to copy a ~270MB file from a Virtio Filesystem to the same Virtio Filesystem improves from ~9 seconds to ~1 second. - The time it takes to compare two identical ~270MB files on the same Virtio Filesystem improves from ~11 seconds to ~3 seconds. Cc: Ard Biesheuvel <ard.biesheuvel@arm.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=3125 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20210113085453.10168-3-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/MemEncryptSevLib: Add an interface to retrieve the encryption maskTom Lendacky2021-01-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 To ensure that we always use a validated encryption mask for an SEV-ES guest, create a new interface in the MemEncryptSevLib library to return the encryption mask. This can be used in place of the multiple locations where CPUID is used to retrieve the value (which would require validation again) and allows the validated mask to be returned. The PEI phase will use the value from the SEV-ES work area. Since the SEV-ES work area isn't valid in the DXE phase, the DXE phase will use the PcdPteMemoryEncryptionAddressOrMask PCD which is set during PEI. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <e12044dc01b21e6fc2e9535760ddf3a38a142a71.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/VirtioFsDxe: convert FUSE inode attributes to EFI_FILE_INFOLaszlo Ersek2020-12-211-0/+1
| | | | | | | | | | | | | | | | | | | | | Introduce the VirtioFsFuseAttrToEfiFileInfo() function, for converting FUSE inode attributes to EFI_FILE_INFO. The EpochToEfiTime() function from EmbeddedPkg's TimeBaseLib proves invaluable for converting the file access times. This is the first time we consume TimeBaseLib in OvmfPkg, so add the necessary lib class resolution. We need not modify any ArmVirtPkg DSC files: see commit af5fed90bfbf ("ArmPlatformPkg,ArmVirtPkg: delete redundant PL031 functions", 2017-05-10). Cc: Ard Biesheuvel <ard.biesheuvel@arm.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=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-22-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: introduce VirtioFsDxeLaszlo Ersek2020-12-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the driver is to ease file exchange (file sharing) between the guest firmware and the virtualization host. The driver is supposed to interoperate with QEMU's "virtiofsd" (Virtio Filesystem Daemon). References: - https://virtio-fs.gitlab.io/ - https://libvirt.org/kbase/virtiofs.html VirtioFsDxe will bind virtio-fs devices, and produce EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them. In the longer term, assuming QEMU will create "bootorder" fw_cfg file entries for virtio-fs devices, booting guest OSes from host-side directories should become possible (dependent on the matching QemuBootOrderLib enhancement). Add the skeleton of the driver. Install EFI_DRIVER_BINDING_PROTOCOL with stub member functions. Install EFI_COMPONENT_NAME2_PROTOCOL with final member functions. This suffices for the DRIVERS command in the UEFI Shell to list the driver with a human-readable name. The file permission model is described immediately in the INF file as a comment block, for future reference. Cc: Ard Biesheuvel <ard.biesheuvel@arm.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=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-2-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.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: Add VariablePolicy engine to OvmfPkg platformBret Barkelew2020-11-171-0/+5
| | | | | | | | | | | 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: enable HttpDynamicCommandVladimir Olovyannikov2020-10-011-0/+4
| | | | | | | | | | | 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: Add RngLib based on TimerLib for CryptoMatthew Carlson2020-09-181-0/+1
| | | | | | | | | | | | | | | | | | | | 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: Create GHCB pages for use during Pei and Dxe phaseTom Lendacky2020-08-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add support to perform SEV-ES initializationTom Lendacky2020-08-171-0/+3
| | | | | | | | | | | | | | | 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: Prepare OvmfPkg to use the VmgExitLib libraryTom Lendacky2020-08-161-0/+1
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Various CpuExceptionHandlerLib libraries will updated to use the new VmgExitLib library. To prevent any build breakage, update the OvmfPkg DSC files that use a form of the CpuExceptionHandlerLib library to include the VmgExitLib library. 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/LsiScsiDxe: Create the empty driverGary Lin2020-07-171-0/+4
| | | | | | | | | | | | | | Create the driver with only a dummy LsiScsiEntryPoint() for the further implementation of the driver for LSI 53C895A SCSI controller. v2: Fix the mixed-case GUID string Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200717061130.8881-2-glin@suse.com>
* OvmfPkg/OvmfPkg*.dsc: Change PCDs type about status codeTan, Ming2020-06-181-3/+3
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786 Since the type of PcdStatusCodeUseSerial and PcdStatusCodeUseMemory in MdeModulePkg.dec are changed, so change them from PcdsFeatureFlag to PcdsFixedAtBuild in dsc files. Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Ming Tan <ming.tan@intel.com>
* Revert "OvmfPkg: use generic QEMU image loader for secure boot enabled ..."Laszlo Ersek2020-06-161-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit ced77332cab626f35fbdb36630be27303d289d79. The command virt-install --location NETWORK-URL downloads the vmlinuz and initrd files from the remote OS tree, and passes them to the guest firmware via fw_cfg. When used with IA32 / X64 guests, virt-install expects the guest firmware to do two things, at the same time: - launch the fw_cfg kernel image even if the latter does not pass SB verification (SB checking is supposed to be bypassed entirely in favor of the Linux/x86 Boot Protocol), - still let the guest kernel perceive SB as enabled. Commit ced77332cab6 prevented this, by removing the Linux/x86 Boot Protocol from such an OVMF image that was built with SECURE_BOOT_ENALBE. While that's the right thing in theory, in practice "virt-install --location NETWORK-URL" is entrenched, and we shouldn't break it. We can tolerate the Linux/x86 Boot Protocol as a one-of-a-kind SB bypass for direct-booted kernels, because: - the fw_cfg content comes from QEMU, and the guest is already at QEMU's mercy, - in the guest, OS boots after the initial installation will use "shim" rather than an fw_cfg kernel, which we can consider somewhat similar to "Audit Mode / Deployed Mode" (~ trust for install, lock down after). Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20200615144514.24597-1-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [lersek@redhat.com: truncate the subject line, originally auto-generated by git-revert, to pacify PatchCheck.py]
* OvmfPkg/PlatformPei: increase memory type info defaultsLaszlo Ersek2020-05-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Any new OVMF binary (containing commit d42fdd6f8384, and built with SMM_REQUIRE) is likely to reboot during its first boot, regardless of whether the variable store is logically empty, or it contains a MemoryTypeInformation variable from an earlier OVMF binary. This "reboot on first boot after OVMF upgrade" occurs despite having eliminated BS Code/Data tracking in earlier parts of this series. Meaning that we've outgrown the bins of those memory types too that matter for SMM security. Eliminating said reboot will make an upgrade to edk2-stable202005 more comfortable for users. Increase the defaults empirically. (The total doesn't exceed 3MB by much.) Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.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=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200508121651.16045-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformPei: extract memory type info defaults to PCDsLaszlo Ersek2020-05-181-0/+13
| | | | | | | | | | | | | | | | | | | | Some OvmfPkg modules already depend on "EmbeddedPkg.dec"; thus, replace the open-coded memory type info defaults in the source code with the EmbeddedPkg PCDs that stand for the same purpose. Consequently, platform builders can override these values with the "--pcd" option of "build", without source code updates. While at it, sort the memory type names alphabetically. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.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=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200508121651.16045-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: Skip initrd command on Xcode toolchainRoman Bolshakov2020-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVMF booting stops with the assert if built with Xcode on macOS: Loading driver at 0x0001FAB8000 EntryPoint=0x0001FABF249 LinuxInitrdDynamicShellCommand.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F218398 ProtectUefiImageCommon - 0x1F218140 - 0x000000001FAB8000 - 0x0000000000008A60 ASSERT_EFI_ERROR (Status = Unsupported) ASSERT LinuxInitrdDynamicShellCommand.c(378): !EFI_ERROR (Status) The assert comes from InitializeHiiPackage() after an attempt to retrieve HII package list from ImageHandle. Xcode still doesn't support HII resource section and LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d93a ("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"), disable initrd command if built with Xcode toolchain Fixes: ec41733cfd10 ("OvmfPkg: add the 'initrd' dynamic shell command") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Use toolchain appropriate CpuExceptionHandlerLibLendacky, Thomas2020-05-111-0/+4
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2340 During the SEC phase, use the XCODE5 CpuExceptionHandlerLib library in place of the standard library when building with the XCODE5 toolchain. The SEC XCODE5 version of the library performs binary patching and should only be used when building with the XCODE5 toolchain. 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> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <0cfdd51deb6d39e08380645f2022b9b76e29f66f.1588856809.git.thomas.lendacky@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* OvmfPkg/MptScsiDxe: Create empty driverNikita Leshenko2020-05-051-0/+4
| | | | | | | | | | | In preparation for implementing LSI Fusion MPT SCSI devices, create a basic scaffolding for a driver. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-2-nikita.leshchenko@oracle.com>
* OvmfPkg: control PXEv4 / PXEv6 boot support from the QEMU command lineLaszlo Ersek2020-04-281-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a minimal, NULL class library called "PxeBcPcdProducerLib" for setting the "PcdIPv4PXESupport" and "PcdIPv6PXESupport" PCDs of NetworkPkg, from fw_cfg. These PCDs control whether the UefiPxeBcDxe driver supports PXEv4 / PXEv6 boot. If a PXE version is disabled, the corresponding LoadFile protocol instance is not produced by UefiPxeBcDxe, and so EfiBootManagerRefreshAllBootOption() in UefiBootManagerLib does not generate corresponding *new* boot options either. (Existent boot options are not deleted.) Hook the library into the UefiPxeBcDxe driver. (The driver is already included from "NetworkComponents.dsc.inc", but we can list it again in the DSC file, for providing <LibraryClasses> overrides.) In OVMF, the PCDs could be set in PlatformPei too, but ArmVirtQemu does not have fw_cfg access in the PEI phase. Hence a NULL class library that can be linked into UefiPxeBcDxe. When listing the PCDs under [PcdsDynamicDefault], stick with the DEC default values. QEMU switches: -fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=[yn] -fw_cfg name=opt/org.tianocore/IPv6PXESupport,string=[yn] The "opt/org.tianocore" prefix follows the "opt/RFQDN/" recommendation from QEMU's "docs/specs/fw_cfg.txt". Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: introduce QemuFwCfgSimpleParserLibLaszlo Ersek2020-04-281-0/+1
| | | | | | | | | | | | | | | | We already parse some boolean and integer values from named fw_cfg files (usually into PCDs), and we're going to cover more. Add a dedicated library for centralizing the parsing logic. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instanceLaszlo Ersek2020-04-221-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BaseResetSystemLib instance is not suitable for OS runtime, because its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID). On q35, this boils down to a memory-mapped config space access -- but we never ask the OS to map MMCONFIG for runtime. There are at least three alternatives to approach this: (1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers some kind of runtime mapping for MMCONFIG. (2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib. Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port accesses on q35 too, not just on i440fx. IO ports don't depend on page tables. (3) In the lib constructor, cache "mAcpiPmBaseAddress" based on "PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the host bridge type will be known at runtime without PCI config space accesses. This patch follows approach (3), in order to mirror AcpiTimerLib. Notes: * This patch is best viewed with "git show --find-copies-harder -C43". * PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD protocol is not available yet. (The DXE_CORE does consume ResetSystemLib in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.) Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-7-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> [lersek@redhat.com: move third Note (with repro info) to BZ comment]
* OvmfPkg/ResetSystemLib: rename to BaseResetSystemLibLaszlo Ersek2020-04-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for introducing DxeResetSystemLib, rename the current (only) ResetSystemLib instance to BaseResetSystemLib. In the DSC files, keep the ResetSystemLib resolution in the same [LibraryClasses] section, but move it near the TimerLib resolution, as the differences between the ResetSystemLib instances will mostly follow those seen under OvmfPkg/Library/AcpiTimerLib. (While OvmfXen does not use "OvmfPkg/Library/AcpiTimerLib", perform the same movement there too, for keeping future DSC diffing simple.) Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-6-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg: remove handling of properties tableArd Biesheuvel2020-04-071-1/+0
| | | | | | | | | | | | | | The UEFI properties table and the associated memory protection feature was severely broken from the start, and has been deprecated for a while. Let's drop all references to it from OVMF so we can safely remove it from the DXE core as well. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* OvmfPkg: Fix SMM/RT driver section alignment for XCODE5/CLANGPDBVitaly Cheptsov2020-04-011-2/+4
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2642 This patch resolves the problem of using memory protection attributes when OVMF firmware is compiled with XCODE5 and CLANGPDB. Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marvin Häuser <mhaeuser@outlook.de> Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com> Message-Id: <20200329132158.35259-2-cheptsov@ispras.ru> Acked-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: fix whitespace issues reported by git-am] [lersek@redhat.com: replace "CC:" tags with "Cc:" ones for PatchCheck.py]
* OvmfPkg/PvScsiDxe: Create empty driverLiran Alon2020-03-301-0/+8
| | | | | | | | | | | In preparation for support booting from PvScsi devices, create a basic scaffolding for a driver. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-2-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformationLaszlo Ersek2020-03-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * In the Intel whitepaper: --v-- A Tour Beyond BIOS -- Secure SMM Communication https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Secure_SMM_Communication.pdf --^-- bullet#3 in section "Assumption and Recommendation", and bullet#4 in "Call for action", recommend enabling the (adaptive) Memory Type Information feature. * In the Intel whitepaper: --v-- A Tour Beyond BIOS -- Memory Map and Practices in UEFI BIOS https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-white-papers https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf --^-- figure#6 describes the Memory Type Information feature in detail; namely as a feedback loop between the Platform PEIM, the DXE IPL PEIM, the DXE Core, and BDS. Implement the missing PlatformPei functionality in OvmfPkg, for fulfilling the Secure SMM Communication recommendation. In the longer term, OVMF should install the WSMT ACPI table, and this patch contributes to that. Notes: - the step in figure#6 where the UEFI variable is copied into the HOB is covered by the DXE IPL PEIM, in the DxeLoadCore() function, - "PcdResetOnMemoryTypeInformationChange" must be reverted to the DEC default TRUE value, because both whitepapers indicate that BDS needs to reset the system if the Memory Type Information changes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-6-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: include FaultTolerantWritePei and VariablePei with -D SMM_REQUIRELaszlo Ersek2020-03-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FaultTolerantWritePei consumes: - PcdFlashNvStorageFtwWorkingBase, - PcdFlashNvStorageFtwSpareBase. VariablePei consumes: - PcdFlashNvStorageVariableBase64. Due to the previous patches in this series, the above PCDs are available in the PEI phase, in the SMM_REQUIRE build. FaultTolerantWritePei produces a GUID-ed HOB with FAULT_TOLERANT_WRITE_LAST_WRITE_DATA as contents. It also installs a Null PPI that carries the same gEdkiiFaultTolerantWriteGuid as the HOB. VariablePei depends on the Null PPI mentioned above with a DEPEX, consumes the HOB (which is safe due to the DEPEX), and produces EFI_PEI_READ_ONLY_VARIABLE2_PPI. This enables read-only access to non-volatile UEFI variables in the PEI phase, in the SMM_REQUIRE build. For now, the DxeLoadCore() function in "MdeModulePkg/Core/DxeIplPeim/DxeLoad.c" will not access the "MemoryTypeInformation" variable, because OVMF's PlatformPei always produces the MemoryTypeInformation HOB. (Note: when the boot mode is BOOT_ON_S3_RESUME, PlatformPei doesn't build the HOB, but that's in sync with DxeLoadCore() also not looking for either the HOB or the UEFI variable.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-5-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: set fixed FlashNvStorage base addresses with -D SMM_REQUIRELaszlo Ersek2020-03-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following flash-related base addresses: - PcdFlashNvStorageVariableBase64, - PcdFlashNvStorageFtwWorkingBase, - PcdFlashNvStorageFtwSpareBase, are always set to constant (invariable) values in the "-D SMM_REQUIRE" build of OVMF. (That's because in the SMM build, actual pflash is a hard requirement, and the RAM-based emulation is never available.) Set said PCDs statically, at build. This will allow us to depend on their values in the PEI phase. When SMM_REQUIRE is FALSE, this change has no effect (confirmed by report file comparison). When SMM_REQUIRE is TRUE, the report file shows the following changes: - "PcdOvmfFlashNvStorageFtwSpareBase" and "PcdOvmfFlashNvStorageFtwWorkingBase" are no longer consumed by any module directly, - for "PcdFlashNvStorageFtwSpareBase", "PcdFlashNvStorageFtwWorkingBase" and "PcdFlashNvStorageVariableBase64", the access method changes from DYN to FIXED, - for the latter PCDs, the zero (dynamic default) values are replaced with the desired constants. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-4-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: use generic QEMU image loader for secure boot enabled buildsArd Biesheuvel2020-03-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QemuLoadImageLib implementation we currently use for all OVMF builds copies the behavior of the QEMU loader code that precedes it, which is to disregard UEFI secure boot policies entirely when it comes to loading kernel images that have been specified on the QEMU command line. This behavior deviates from ArmVirtQemu based builds, which do take UEFI secure boot policies into account, and refuse to load images from the command line that cannot be authenticated. The disparity was originally due to the fact that the QEMU command line kernel loader did not use LoadImage and StartImage at all, but this changed recently, and now, there are only a couple of reasons left to stick with the legacy loader: - it permits loading images that lack a valid PE/COFF header, - it permits loading X64 kernels on IA32 firmware running on a X64 capable system. Since every non-authentic PE/COFF image can trivially be converted into an image that lacks a valid PE/COFF header, the former case can simply not be supported in a UEFI secure boot context. The latter case is highly theoretical, given that one could easily switch to native X64 firmware in a VM scenario. That leaves us with little justification to use the legacy loader at all when UEFI secure boot policies are in effect, so let's switch to the generic loader for UEFI secure boot enabled builds. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add new QEMU kernel image loader componentsArd Biesheuvel2020-03-051-0/+2
| | | | | | | | | | Add the components that expose the QEMU abstract loader file system so that we can switch over our PlatformBmLib over to it in a subsequent patch. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: clone CpuS3DataDxe from UefiCpuPkgLaszlo Ersek2020-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The @file comments in UefiCpuPkg/CpuS3DataDxe say, [...] It also only supports the number of CPUs reported by the MP Services Protocol, so this module does not support hot plug CPUs. This module can be copied into a CPU specific package and customized if these additional features are required. [...] The driver is so small that the simplest way to extend it with hotplug support is indeed to clone it at first. In this patch, customize the driver only with the following no-op steps: - Update copyright notices. - Update INF_VERSION to the latest INF spec version (1.29). - Update FILE_GUID. - Drop the UNI files. - Replace EFI_D_VERBOSE with DEBUG_VERBOSE, to appease "PatchCheck.py". This patch is best reviewed with: $ git show --find-copies-harder Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-15-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg/CpuHotplugSmm: introduce skeleton for CPU Hotplug SMM driverLaszlo Ersek2020-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new SMM driver skeleton that registers a root SMI handler, and checks if the SMI control value (written to 0xB2) indicates a CPU hotplug SMI. QEMU's ACPI payload will cause the OS to raise a broadcast SMI when a CPU hotplug event occurs, namely by writing value 4 to IO Port 0xB2. In other words, control value 4 is now allocated for this purpose; introduce the ICH9_APM_CNT_CPU_HOTPLUG macro for it. The standard identifiers in this driver use the new MM (Management Mode) terminology from the PI spec, not the earlier SMM (System Management Mode) terms. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-7-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg: enable CPU hotplug support in PiSmmCpuDxeSmmLaszlo Ersek2020-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set "PcdCpuHotPlugSupport" to TRUE, when OVMF is built with SMM_REQUIRE. Consequences: (1) In PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c], resources are allocated and populated in advance for all possible (i.e., potentially hot-added) processors, rather than only the processors present at boot. The possible count (called "mMaxNumberOfCpus") is set from "PcdCpuMaxLogicalProcessorNumber"; we set the latter in OvmfPkg/PlatformPei. (Refer to commit 83357313dd67, "OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplug", 2020-01-29). (2) The AddProcessor() and RemoveProcessor() member functions of EFI_SMM_CPU_SERVICE_PROTOCOL, implemented in "UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c", are no longer short-circuited to EFI_UNSUPPORTED. We'll rely on these functions in the CPU hotplug SMI handler, in a subsequent patch. (3) In PiCpuSmmEntry(), the address of the CPU_HOT_PLUG_DATA structure (in SMRAM) is exposed via the dynamic-only "PcdCpuHotPlugDataAddress". This structure is an information channel between the CPU hotplug SMI handler, and EFI_SMM_CPU_SERVICE_PROTOCOL. Namely, at the first "Index" where the following equality holds: CPU_HOT_PLUG_DATA.ApicId[Index] == INVALID_APIC_ID a hot-plugged CPU can be accepted, with the steps below: (3.1) The hotplug SMI handler has to overwrite INVALID_APIC_ID with the new CPU's APIC ID. (3.2) The new CPU's SMBASE has to be relocated to: CPU_HOT_PLUG_DATA.SmBase[Index] (which was precomputed in step (1) above). (3.3) The hotplug SMI handler is supposed to call EFI_SMM_CPU_SERVICE_PROTOCOL.AddProcessor(). Note: we need not spell out "PcdCpuHotPlugDataAddress" in the [PcdsDynamicDefault] sections of the OVMF DSC files, just so the PCD become dynamically settable. That's because "UefiCpuPkg.dec" declares this PCD with [PcdsDynamic, PcdsDynamicEx] access methods *only*. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg: enable SMM Monarch Election in PiSmmCpuDxeSmmLaszlo Ersek2020-03-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With "PcdCpuSmmEnableBspElection" set to FALSE, PiSmmCpuDxeSmm always considers the processor with index 0 to be the SMM Monarch (a.k.a. the SMM BSP). The SMM Monarch handles the SMI for real, while the other CPUs wait in their SMM loops. In a subsequent patch, we want to set "PcdCpuHotPlugSupport" to TRUE. For that, PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c] forces us with an ASSERT() to set "PcdCpuSmmEnableBspElection" to TRUE as well. To satisfy that expectation, we can simply remove our current "PcdCpuSmmEnableBspElection|FALSE" setting, and inherit the default TRUE value from "UefiCpuPkg.dec". This causes "mSmmMpSyncData->BspIndex" in PiSmmCpuDxeSmm to lose its static zero value (standing for CPU#0); instead it becomes (-1) in general, and the SMM Monarch is elected anew on every SMI. The default SMM Monarch Election is basically a race -- whichever CPU can flip "mSmmMpSyncData->BspIndex" from (-1) to its own index, becomes king, for handling that SMI. Refer to SmiRendezvous() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]. I consider this non-determinism less than ideal on QEMU/KVM; it would be nice to stick with a "mostly permanent" SMM Monarch even with the Election enabled. We can do that by implementing the PlatformSmmBspElection() API in the SmmCpuPlatformHookLibQemu instance: The IA32 APIC Base MSR can be read on each CPU concurrently, and it will report the BSP bit as set only on the current Boot Service Processor. QEMU marks CPU#0 as the BSP, by default. Elect the current BSP, as reported by QEMU, for the SMM Monarch role. (Note that the QEMU commit history is not entirely consistent on whether QEMU/KVM may mark a CPU with nonzero index as the BSP: - At tag v4.2.0, "target/i386/cpu.c" has a comment saying "We hard-wire the BSP to the first CPU". This comment goes back to commit 6cb2996cef5e ("x86: Extend validity of bsp_to_cpu", 2010-03-04). - Compare commit 9cb11fd7539b ("target-i386: clear bsp bit when designating bsp", 2015-04-02) though, especially considering KVM. Either way, this OvmfPkg patch is *not* dependent on CPU index 0; it just takes the race on every SMI out of the game.) One benefit of using a "mostly permanent" SMM Monarch / BSP is that we can continue testing the SMM CPU synchronization by deterministically entering the firmware on the BSP, vs. on an AP, from Linux guests: $ time taskset -c 0 efibootmgr $ time taskset -c 1 efibootmgr (See <https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt#uefi-variable-access-test>.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c5 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg: clone SmmCpuPlatformHookLib from UefiCpuPkgLaszlo Ersek2020-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clone the Null instance of SmmCpuPlatformHookLib from UefiCpuPkg to OvmfPkg. In this patch, customize the lib instance only with the following no-op steps: - Replace Null/NULL references in filenames and comments with Qemu/QEMU references. - Update copyright notices. - Clean up and rewrap comment blocks. - Update INF_VERSION to the latest INF spec version (1.29). - Update FILE_GUID. - Drop the UNI file. This patch is best reviewed with: $ git show --find-copies=43 --find-copies-harder Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg: plug DxeTpmMeasureBootLib into SecurityStubDxeMarc-André Lureau2020-03-041-0/+1
| | | | | | | | | | Mirrors TPM 2.0 commit d5a002aba0aa ("OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe", 2018-03-09) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-6-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg: include TcgDxe moduleMarc-André Lureau2020-03-041-0/+5
| | | | | | | | | | Mirrors TPM 2.0 commit 0c0a50d6b3ff ("OvmfPkg: include Tcg2Dxe module", 2018-03-09). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-5-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg: include TcgPei moduleMarc-André Lureau2020-03-041-0/+1
| | | | | | | | | | Mirrors TPM 2.0 commit 4672a4892867 ("OvmfPkg: include Tcg2Pei module", 2018-03-09). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-4-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg: detect TPM 1.2 in Tcg2ConfigPeiMarc-André Lureau2020-03-041-0/+2
| | | | | | | | | | | | | | | | Complement commit 6cf1880fb5b ("OvmfPkg: add customized Tcg2ConfigPei clone", 2018-03-09) by detecting TPM 1.2 devices. Since Tpm12RequestUseTpm() returns success on any TPM interface, (including FIFO & CRB which are TPM 2.0), try to send a GetTicks TPM 1.2 command to probe the version. In case of failure, fallback on TPM 2.0 path. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Message-Id: <20200226152433.1295789-3-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg: rename TPM2 config prefix to TPMMarc-André Lureau2020-03-041-12/+12
| | | | | | | | | | | A following patch is going to use the same configuration for TPM1.2 and TPM2.0, and it's simpler to support both than variable configurations. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-2-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg: add the 'initrd' dynamic shell commandArd Biesheuvel2020-03-041-0/+4
| | | | | | | | | | Add the 'initrd' dynamic shell command to the build so we can load Linux initrds straight from the shell using the new generic protocol, which does not rely on initrd= being passed on the command line. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: introduce PcdCsmEnable feature flagLaszlo Ersek2020-02-051-0/+3
| | | | | | | | | | | | | | | | | | | | | 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: introduce PcdQ35SmramAtDefaultSmbaseLaszlo Ersek2020-02-051-0/+1
| | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 06:49:40 +0000