summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: VirtioBlkDxe: reset device at ExitBootServices()Laszlo Ersek2015-10-162-1/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | (1) VirtioLib allocates the virtio ring in EfiBootServicesData memory. (This is intentional.) Code that executes after ExitBootServices() is permitted to reuse such memory. (2) The hypervisor is allowed to look at, and act upon, a live virtio ring at any time, even without explicit virtio kicks from the guest. Should boot loader code or kernel code, running between ExitBootServices() and the kernel's own virtio drivers resetting the device, overwrite the pages that used to contain the virtio ring before ExitBootServices(), QEMU could theoretically interpret that unrelated data as garbage ring contents, and abort the guest. Although we have seen no such reports, better be prudent and reset the device in an ExitBootServices() event handler. Among other things, this causes QEMU to forget about the device's virtio ring. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18624 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: VirtioScsiDxe: reset device at ExitBootServices()Laszlo Ersek2015-10-162-2/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | (1) VirtioLib allocates the virtio ring in EfiBootServicesData memory. (This is intentional.) Code that executes after ExitBootServices() is permitted to reuse such memory. (2) The hypervisor is allowed to look at, and act upon, a live virtio ring at any time, even without explicit virtio kicks from the guest. Should boot loader code or kernel code, running between ExitBootServices() and the kernel's own virtio drivers resetting the device, overwrite the pages that used to contain the virtio ring before ExitBootServices(), QEMU could theoretically interpret that unrelated data as garbage ring contents, and abort the guest. Although we have seen no such reports, better be prudent and reset the device in an ExitBootServices() event handler. Among other things, this causes QEMU to forget about the device's virtio ring. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18623 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Sec: Fix SOURCE_DEBUG_ENABLE ASSERT()Michael Kinney2015-10-162-2/+12
| | | | | | | | | | | | | | | | | | | | | The update to the LocalApicLib instances to make sure the Local APIC is initialized before use (SVN r18595 / git commit 6d72ff7d9daf) generates an ASSERT() when SOURCE_DEBUG_ENABLE is enabled for OVMF. The fix is to initialize the Local APIC Timer and mask it before initializing the DebugAgent. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: rewrap code comment, rewrap commit msg, add precise commit ref] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18622 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: raise DXEFV size to 9 MBGary Ching-Pang Lin2015-10-073-9/+9
| | | | | | | | | | | | | | | | | With gcc5 and enabling SECURE_BOOT and NETWORK_IP6, the build failed with this error: GenFv: ERROR 3000: Invalid the required fv image size 0x814c18 exceeds the set fv image size 0x800000 Raise the DXEFV size to 9 MB to fix the build error. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Ching-Pang Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18577 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: set 4 KB section alignment for DXE_RUNTIME_DRIVER modulesArd Biesheuvel2015-09-303-0/+9
| | | | | | | | | | | | | | | | Increase the section alignment to 4 KB for DXE_RUNTIME_DRIVER modules. This allows the OS to map them with tightened permissions (i.e., R-X for .text and RW- for .data). This is a prerequisite for enabling the EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA (sic) feature that was introduced in UEFIv2.5. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18564 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: build the TFTP command into the UEFI shellLaszlo Ersek2015-09-253-0/+3
| | | | | | | | | | | | | | | | | | | The TFTP command is easy to use, it has very nice documentation (accessible with "HELP TFTP" in the shell), and it's a very versatile tool for downloading files from the host to the guest, via virtual network, while the guest is in the UEFI shell. Even better, enabling this command in the shell increases the uncompressed DXEFV size only by 12896 bytes, in my X64 build, and the final size increase (after LZMA compression) that is visible in the FVMAIN_COMPACT volume is merely 2576 bytes. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18554 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: enable SATA controllerReza Jelveh2015-09-226-12/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this patch, we replace the traditional IDE driver stack that comes from PcAtChipsetPkg and IntelFrameworkModulePkg with more featureful drivers from OvmfPkg and MdeModulePkg. The resultant driver stack is compatible with the previous one, but provides more protocols, on more kinds of virtual hardware. Remove: - PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf (removing EFI_IDE_CONTROLLER_INIT_PROTOCOL [1]) Remove the dependent: - IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf (removing EFI_DISK_INFO_PROTOCOL [2], EFI_BLOCK_IO_PROTOCOL [3]) As replacement, add: - OvmfPkg/SataControllerDxe/SataControllerDxe.inf (supplying EFI_IDE_CONTROLLER_INIT_PROTOCOL [1]) On top of which, add the dependent: - MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf (providing EFI_ATA_PASS_THRU_PROTOCOL, EFI_EXT_SCSI_PASS_THRU_PROTOCOL) On top of which, add the dependent: - MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf (supplying EFI_DISK_INFO_PROTOCOL [2], EFI_BLOCK_IO_PROTOCOL [3], providing EFI_BLOCK_IO2PROTOCOL, EFI_STORAGE_SECURITY_COMMAND_PROTOCOL) Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de> [lersek@redhat.com: rewrote commit message] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18532 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuBootOrderLib: recognize Q35 SATA disks / CD-ROMsLaszlo Ersek2015-09-221-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OpenFirmware device paths that QEMU generates for these disks and CD-ROMs are very similar to those generated for the i440fx IDE disks and CD-ROMs (including the same number of devpath nodes necessary for unique parsing). The interpretations and the translation to UEFI devpath fragments are different, of course. (The spaces after "ide@1,1" are inserted below only for illustration purposes.) primary or secondary | master or slave v v i440fx IDE: /pci@i0cf8/ide@1,1 /drive@0/disk@0 Q35 SATA: /pci@i0cf8/pci8086,2922@1f,2/drive@1/disk@0 ^ ^ | device number | (fixed 0) channel (port) number The similarity is reflected in the translation output (spaces again inserted for illustration only): i440fx IDE: PciRoot(0x0)/Pci(0x1,0x1) /Ata(Primary,Master,0x0) Q35 SATA: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0) ^ ^ ^ | | LUN; | | always 0 on Q35 | port multiplier port | number; always 0 on Q35 channel (port) number Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18531 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: SataControllerDxe: enable IO / mem access and DMA when bindingLaszlo Ersek2015-09-222-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we bind the SATA controller in SataControllerStart(), we read the NP ("Number of Ports") bitfield from the CAP ("HBA Capabilities") register of the controller. (See the AHCI 1.3.1 spec.) This register is memory mapped. If we'd like to access it, we must at least enable memory space access for the device. In addition, Feng Tian recommended enabling Bus Master DMA in <http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10545/focus=10659>. We also enable IO space access for completeness. Further, because we change the PCI attributes of the device with the above when binding it, we must also restore its original PCI attributes when unbinding it. See the Driver Writer's Guide for UEFI 2.3.1 v1.01, section 18.3 "PCI drivers" | 18.3.2 "Start() and Stop()". (OvmfPkg's copy of SataControllerDxe differs from the same in DuetPkg because Duet inherits a pre-configured SATA controller from the BIOS, as explained by Feng. Technically, DuetPkg's SataControllerDxe could also apply the technique seen in this patch.) Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu> Cc: Feng Tian <feng.tian@intel.com> Suggested-by: Feng Tian <feng.tian@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Feng Tian <feng.tian@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18528 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: SataControllerDxe: add cascading error handling to Start()Laszlo Ersek2015-09-221-27/+32
| | | | | | | | | | | | | | | | | | | | | | In the next patch we'll add another PCI operation to SataControllerStart(), which, on error, has to be rolled back similarly to other actions already being done in SataControllerStart(). Since that PCI operation won't provide a non-NULL pointer on success, its rollback isn't really suitable for the current error handling in SataControllerStart(). Employ the traditional cascading labels instead. Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18527 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: copy SataControllerDxe from DuetPkgReza Jelveh2015-09-224-0/+1816
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Edk2 maintainers reached the consensus that SataControllerDxe was inherently platform specific, for which reason it was not appropriate for either PcAtChipsetPkg nor MdeModulePkg. Hence, if OvmfPkg wanted to use it, it should either reference it directly from under DuetPkg, or copy it. Given that DuetPkg is another "leaf" platform in edk2, and that in the upcoming patches we'll actually modify the driver, the ultimate decision (reached months ago on the list, after Reza's v2 posting) is that OvmfPkg shall copy the driver. This patch does that; the only difference being a fresh FILE_GUID in the INF file. Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de> [lersek@redhat.com: updated commit message, generated fresh FILE_GUID] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18526 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/build.sh: Use GCC49 toolchain with GCC 5.*Jordan Justen2015-09-181-1/+1
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18514 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: disable no-exec DXE stack by defaultLaszlo Ersek2015-09-153-3/+3
| | | | | | | | | | | | | | | | | | | (PcdSetNxForStack == TRUE) breaks a number of GRUB versions that, it turns out, are still widely in use. Disable PcdSetNxForStack by default for now. QEMU users can enable it dynamically using the micro-feature added in the previous patch. Reported-by: Anthony Perard <anthony.perard@citrix.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: Ian Campbell <Ian.Campbell@citrix.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Josh Triplett <josh@joshtriplett.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ian Campbell <Ian.Campbell@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18472 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: take no-exec DXE settings from the QEMU command lineLaszlo Ersek2015-09-152-2/+65
| | | | | | | | | | | | | | | | | | | | | | Control them with: -fw_cfg name=opt/ovmf/PcdPropertiesTableEnable,file=no.txt \ -fw_cfg name=opt/ovmf/PcdSetNxForStack,file=yes.txt where the contents of the text files can be [0nN1yY](\n|\r\n)? The macro trickery is not optimal, but it is caused by PcdSetBool(), which is itself a macro, and can only take open-coded PCD names (ie. no variables, like function parameters). Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18471 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: make PcdPropertiesTableEnable dynamicLaszlo Ersek2015-09-153-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since PcdPropertiesTableEnable is used by the DXE Core (in the InstallPropertiesTable() function, which runs at End-of-Dxe), we must also change the PcdLib class resolution for that module, from the default BasePcdLibNull to DxePcdLib. Traditionally we've considered the DXE Core to be incapable of accessing dynamic PCDs -- the PCD PPI is not available any longer to the DXE Core, and the PCD Protocol is not available to it *yet*. There are exceptions however: if the DXE Core can ensure, by whatever means, that the PCD Protocol *is* available, then DxePcdLib will just work (the latter even lists DXE_CORE as an allowed client module type). Namely, DxePcdLib looks up the PCD Protocol dynamically, on the first library call that actually needs it (for accessing a dynamic PCD); the lookup doesn't occur in a library constructor. And because the DXE Core fetches PcdPropertiesTableEnable at End-of-Dxe, the PCD Protocol is definitely available then. In addition, we change the default value of PcdPropertiesTableEnable from the inherited TRUE to FALSE. It makes no difference at this point (our runtime DXE drivers are not built with the required 4KB section alignment anyway), but it's better to be clear about this. The properties table feature requires OS compatibility, and it breaks Windows 7 minimally. Therefore the default should be FALSE. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18470 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: make PcdSetNxForStack dynamicLaszlo Ersek2015-09-153-6/+21
| | | | | | | | | | | | | | | Plus, because PcdSetNxForStack is used by the DXE IPL PEIM (in the HandOffToDxeCore() function, and in the CreateIdentityMappingPageTables() function called by the former), we must change the PcdLib class resolution for that module, from the default BasePcdLibNull to PeiPcdLib. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18469 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: force 32-bit MMIO aperture above 3 GB on Q35Laszlo Ersek2015-09-021-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic we have in place for i440fx does not work reliably on q35. For example, if the guest has 2GB of RAM, we allow the PCI root bridge driver to allocate the legacy video RAM BAR from the [2048 MB, 2816 MB] range, which falls strictly outside of the Q35 PCI host MMIO aperture that QEMU configures, and advertizes in ACPI. In turn, PCI BARs that exist outside of the PCI host aperture that is exposed in ACPI break Windows guests. Allocating PCI MMIO resources at or above 3GB on Q35 ensures that we stay within QEMU's aperture. (See the "w32.begin" assignments in "hw/pci-host/q35.c".) Furthermore, in pc_q35_init() (file "hw/i386/pc_q35.c"), QEMU ensures that the low RAM never "leaks" above 3GB. The i440fx logic is left unchanged. The Windows guest malfunction on Q35 was reported by Jon Panozzo of Lime Technology, Inc. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jon Panozzo <jonp@lime-technology.com> Cc: "Gabriel L. Somlo" <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Jonathan Panozzo <jonp@lime-technology.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18393 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiTables: serialize control methods that create named objectsLaszlo Ersek2015-09-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bruce Cran reported the following issue: With iasl version 20150410-64 building OvmfX64 (using OvmfPkg/build.sh -a X64 -t GCC49 -b RELEASE) results in a couple of warnings about methods that should be serialized: .../OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.iiii 95: Method (_CRS, 0) { Remark 2120 - Control Method should be made Serialized ^ (due to creation of named objects within) .../OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.iiii 235: Method (PCRS, 1, NotSerialized) { Remark 2120 - Control Method should be made Serialized ^ (due to creation of named objects within) The ACPI 6.0 spec justifies the above warnings in "19.6.82 Method (Declare Control Method)": [...] The serialize rule can be used to prevent reentering of a method. This is especially useful if the method creates namespace objects. Without the serialize rule, the reentering of a method will fail when it attempts to create the same namespace object. [...] Cc: Bruce Cran <bruce@cran.org.uk> Reported-by: Bruce Cran <bruce@cran.org.uk> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18392 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: clear CMOS 0xF after setting mBootModeLaszlo Ersek2015-09-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | We have an old bug in BootModeInitialization(): firmware is supposed to clear the CMOS register 0xF after reading it for the last time. QEMU only sets this register to 0xFE in "hw/timer/mc146818rtc.c", function rtc_notify_suspend(), and never clears it. However, SeaBIOS does clear it in "src/post.c" and "src/resume.c", so let's follow suit. We've never noticed this until now because the register gets mysteriously cleared on non-resume reboots when OVMF runs on qemu-system-x86_64. But on qemu-system-i386, this bug breaks a (suspend, resume, reboot) triplet: after the last step OVMF thinks it's resuming because when it actually resumed (in the middle step), it failed to clear the register. BootModeInitialization() is the perfect function to clear the register, right after setting mBootMode: the function is executed on both normal boot and on S3 resume; it succeeds DebugDumpCmos() -- so the dump is not affected by this patch --; and everything that relies on S3 vs. normal boot after we clear the register uses mBootMode anyway. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18391 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: prevent code execution from DXE stackLaszlo Ersek2015-08-283-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SVN rev 18166 ("MdeModulePkg DxeIpl: Add stack NX support") enables platforms to request non-executable stack for the DXE phase, by setting PcdSetNxForStack to TRUE. The PCD defaults to FALSE, because: (a) A non-executable DXE stack is a new feature and causes changes in behavior. Some platform could rely on executing code from the stack. (b) The code enabling NX in the DXE IPL PEIM enforces the PcdSetNxForStack ==> PcdDxeIplBuildPageTables implication for "64-bit PEI + 64-bit DXE" platforms, with a new ASSERT(). Some platform might not comply with this requirement immediately. Regarding (a), in none of the OVMF builds do we try to execute code from the stack. Regarding (b): - In the OvmfPkgX64.dsc build (which is where (b) applies) we simply inherit the PcdDxeIplBuildPageTables|TRUE default from "MdeModulePkg/MdeModulePkg.dec". Therefore we can set PcdSetNxForStack to TRUE. - In OvmfPkgIa32X64.dsc, page tables are built by default for DXE. Hence we can set PcdSetNxForStack to TRUE. - In OvmfPkgIa32.dsc, page tables used not to be necessary until now. After we set PcdSetNxForStack to TRUE in this patch, the DXE IPL will construct page tables even when it is built as part of OvmfPkgIa32.dsc, provided the (virtual) hardware supports both PAE mode and the XD bit. Should this setting cause problems in a GPU (or other device) passthru scenario, with a UEFI_DRIVER in the PCI option rom attempting to execute code from the stack, the feature can be dynamically disabled on the QEMU command line, with "-cpu <MODEL>,-nx". Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: "Zeng, Star" <star.zeng@intel.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18360 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Build HTTP utilities driverGary Ching-Pang Lin2015-08-286-0/+6
| | | | | | | | | | | | Since SVN r18316 / git 5ca29abe5297, the HTTP driver needs the HTTP utilities driver to parse the headers of HTTP requests. Add the driver into OVMF so that the HTTP driver can work properly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Ching-Pang Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18359 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Link separated VarCheckUefiLib NULL class library instanceStar Zeng2015-08-253-3/+12
| | | | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18288 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add VarCheckLib library mappingStar Zeng2015-08-253-0/+3
| | | | | | | | | | | | Since Variable driver has been updated to consume the separated VarCheckLib. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18281 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add HttpBoot supportGary Ching-Pang Lin2015-08-236-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit introdues a new build option to OvmfPkg: HTTP_BOOT_ENABLE. When HttpBoot is enabled, a new Network boot option will show in the boot manager menu with the device path like this: PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0)/Uri() It works like the PXE one but fetches the NBP from the given http url instead of the tftp service. A simple testing environment can be set up with the QEMU tap network and dnsmasq + lighttpd. Here is the example of the dnsmasq config: interface=<tap interface> dhcp-range=192.168.111.100,192.168.111.120,12h dhcp-option=60,"HTTPClient" dhcp-boot="http://<tap ip>/<efi file>" It's similar to the PXE server settings except the tftp function is disabled, the option 60 must be "HTTPClient", and the boot uri is a http url. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Ching-Pang Lin <glin@suse.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18258 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/Xen: use lower case x in hex immediate valueArd Biesheuvel2015-08-111-1/+1
| | | | | | | | | | | The Clang assembler for AArch64 chokes on the value 0XEA1 since it expects the 0x prefix to use a lower case x. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18204 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: SmbiosVersionLib: recognize SMBIOS 3.x entry pointLaszlo Ersek2015-08-065-0/+21
| | | | | | | | | | | | | | | Also set the DocRev field the way QEMU exposes it, because MdeModulePkg/Universal/SmbiosDxe lets us control that field too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Wei Huang <wei@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18182 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: SmbiosPlatformDxe: eliminate duplicate entry point validationLaszlo Ersek2015-08-064-21/+28
| | | | | | | | | | | | | | | | | | | | | | At this point all platforms that use OvmfPkg/SmbiosPlatformDxe in edk2, namely ArmVirtQemu.dsc and OvmfPkg*.dsc, have been migrated to SmbiosVersionLib. Therefore SmbiosPlatformDxe itself can forego verifying QEMU's SMBIOS entry point; if SmbiosVersionLib's validation was successful, it should just rely on that. (Note that SmbiosPlatformDxe has a depex on EFI_SMBIOS_PROTOCOL, installed by SmbiosDxe, containing SmbiosVersionLib, therefore the set/get order of PcdQemuSmbiosValidated is ensured.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Wei Huang <wei@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18180 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: introduce PcdQemuSmbiosValidatedLaszlo Ersek2015-08-064-0/+4
| | | | | | | | | | | | | | | | | | | This dynamic PCD will enable a small code de-duplication between OvmfPkg/SmbiosPlatformDxe and OvmfPkg/Library/SmbiosVersionLib. Since both of those are also used in ArmVirtQemu.dsc, and we should avoid cross-package commits when possible, this patch declares PcdQemuSmbiosValidated first, and sets defaults for it in the OvmfPkg DSC files. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Wei Huang <wei@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18178 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: set SMBIOS version in DetectSmbiosVersionLib instead of PlatformPeiLaszlo Ersek2015-08-065-44/+12
| | | | | | | | | | | | | | | | | | | | | | | | | This patch de-duplicates the logic added in commit OvmfPkg: PlatformPei: set SMBIOS entry point version dynamically (git 37baf06b, SVN r17676) by hooking DetectSmbiosVersionLib into SmbiosDxe. Although said commit was supposed to work with SMBIOS 3.0 payloads from QEMU, in practice that never worked, because the size / signature checks in SmbiosVersionInitialization() would always fail, due to the SMBIOS 3.0 entry point being structurally different. Therefore this patch doesn't regress OvmfPkg. Cc: Wei Huang <wei@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18175 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: SmbiosVersionLib: add "plugin" for detecting SMBIOS versionLaszlo Ersek2015-08-062-0/+127
| | | | | | | | | | | | | | | | | | | | | Introduce a minimal library instance for fetching and validating the SMBIOS entry point structure exposed by QEMU over fw_cfg. This library is meant to be hooked into MdeModulePkg/Universal/SmbiosDxe by platform DSC files, so that the library can set the PCD(s) that SmbiosDxe consumes at the right moment. At the moment only SMBIOS 2.x entry points are recognized. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Wei Huang <wei@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18174 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformDebugLibIoPort: fix AsciiSPrint() format stringLaszlo Ersek2015-08-061-1/+2
| | | | | | | | | | | | | | | | | | | | | The LineNumber parameter of the DebugAssert() function has type UINTN. DebugAssert() passes it to AsciiSPrint() with the %d conversion specifier at the moment, but %d would require an INT32 argument. Fix this by casting LineNumber to UINT64, also employing the matching decimal conversion specifier, %Lu. (Another possibility would be to cast LineNumber to INT32, but a UINTN->INT32 cast is not value preserving, generally speaking.) Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Scott Duplichan <scott@notabs.org> Reported-by: Scott Duplichan <scott@notabs.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18173 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: fix conversion specifiers in DEBUG format stringsLaszlo Ersek2015-07-2813-36/+52
| | | | | | | | | | | | Cc: Scott Duplichan <scott@notabs.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Reported-by: Scott Duplichan <scott@notabs.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18095 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: SmbiosPlatformDxe: restrict current Xen code to IA32/X64Laszlo Ersek2015-07-263-2/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Xen code in SmbiosPlatformDxe is centered on the informational HOB with GUID gEfiXenInfoGuid, and the address constants XEN_SMBIOS_PHYSICAL_ADDRESS=0x000EB000, XEN_SMBIOS_PHYSICAL_END=0x000F0000. This Xen hand-off mechanism is specific to the IA32 and X64 architectures, and it is very unlikely that a future ARM / AARCH64 implementation would follow it. Therefore, sequester the IA32 / X64 specific code from the rest of the source, by renaming "Xen.c" to "X86Xen.c", and adding a GetXenSmbiosTables() stub function in "ArmXen.c" that returns NULL. (Those file names are inspired by "OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c".) The call site in SmbiosTablePublishEntry() [SmbiosPlatformDxe.c] is aware that a NULL return value means "Xen SMBIOS tables not found", and will continue to the QEMU tables (for which the retrieval mechanism is shared by x86 and Arm). This change enables SmbiosPlatformDxe for ARM architectures; update the VALID_ARCHITECTURES comment accordingly. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18040 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: SmbiosPlatformDxe: move IsEntryPointStructureValid() to Xen.cLaszlo Ersek2015-07-263-50/+35
| | | | | | | | | | | | | | | | This function is only called from Xen.c, so it should be defined in Xen.c and have internal linkage (ie. STATIC). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18039 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiS3SaveDxe: drop EFI_ACPI_S3_SAVE_PROTOCOLLaszlo Ersek2015-07-263-139/+16
| | | | | | | | | | | | At this point, nothing in the OVMF build calls EFI_ACPI_S3_SAVE_PROTOCOL member functions; simplify the code by dropping this protocol interface. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18038 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: install DxeSmmReadyToLock in PlatformBdsLibLaszlo Ersek2015-07-265-52/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we have the following call chain in OVMF: PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] // // signals End-of-Dxe // OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c] S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c] // // 1. saves S3 state // SaveS3BootScript() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c] // // 2. saves INFO opcode in S3 boot script // 3. installs DxeSmmReadyToLockProtocol // The bottom of this call chain was introduced in git commit 5a217a06 (SVN r15305, "OvmfPkg: S3 Suspend: save boot script after ACPI context"). That patch was necessary because there was no other way, due to GenericBdsLib calling S3Save() from BdsLibBootViaBootOption(), to perform the necessary steps in the right order: - save S3 system information, - save a final (well, only) boot script opcode, - signal DxeSmmReadyToLock, closing the boot script, and locking down LockBox and SMM. The GenericBdsLib bug has been fixed in the previous patch -- the call in BdsLibBootViaBootOption() has been eliminated. Therefore, hoist the SaveS3BootScript() code, and call, from OvmfPkg/AcpiS3SaveDxe, to PlatformBdsLib: PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] // // signals End-of-Dxe // OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c] S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c] // // 1. saves S3 state // <--- SaveS3BootScript() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] // // 2. saves INFO opcode in S3 boot script // 3. installs DxeSmmReadyToLockProtocol // The installation of DxeSmmReadyToLockProtocol belongs with Platform BDS, not AcpiS3SaveDxe, and we can now undo the hack in SVN r15305, without upsetting the relative order of the steps. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18037 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformBdsLib: signal End-of-Dxe event groupLaszlo Ersek2015-07-263-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Paraphrasing git commit 9cd7d3c5 / SVN r17713:) Currently, OvmfPkg fails to signal the End-of-Dxe event group when entering the BDS phase, which results in some loss of functionality, eg. variable reclaim in the variable driver, and the memory region splitting in the DXE core that belongs to the properties table feature specified in UEFI-2.5. As discussed on the edk2-devel mailing list here: http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16109 it is up to the platform BDS to signal End-of-Dxe, since there may be platform specific ordering constraints with respect to the signalling of the event that are difficult to honor at the generic level. (OvmfPkg specifics:) (1) In OvmfPkg, we can't signal End-of-Dxe before PCI enumeration completes. According to the previous patch, that would trigger OvmfPkg/AcpiS3SaveDxe to save S3 state *before* the following chain of action happened: - PCI enumeration completes - ACPI tables are installed by OvmfPkg/AcpiPlatformDxe - the FACS table becomes available Since OvmfPkg/AcpiS3SaveDxe can only save S3 state once the FACS table is available, we must delay the End-of-Dxe signal until after PCI enumeration completes (ie. root bridges are connected). (2) Pre-patch, S3Ready() in OvmfPkg/AcpiS3SaveDxe is entered from BdsLibBootViaBootOption() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]. After the patch, we enter S3Ready() earlier than that, by signaling End-of-Dxe in PlatformBdsPolicyBehavior(). The timing / location of this new call is correct as well, and the original call (that now becomes the chronologically second call) becomes a no-op: S3Ready() is protected against 2nd and later entries. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18035 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiS3SaveDxe: call S3Ready() at End-of-DxeLaszlo Ersek2015-07-262-0/+47
| | | | | | | | | | | | | | | | | | | | | Call S3Ready() whenever the first of the following occurs: - a driver signals End-of-Dxe, - a driver calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save(). S3Ready() already contains a static, function scope "latch" that causes it to exit early when called for the second time or later. (At the moment, the only platform in the edk2 tree that includes this driver is OvmfPkg. That platform does not signal End-of-Dxe (yet).) http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146 Suggested-by: Yao Jiewen <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18034 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiS3SaveDxe: prepare for End-of-Dxe callbackLaszlo Ersek2015-07-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are preparing for detaching the S3Ready() functionality from the EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() protocol member function. Instead, we will hook the same logic to the End-of-Dxe event group. The EFI_ACPI_S3_SAVE_PROTOCOL has another member: GetLegacyMemorySize(). According to the documenation, This function returns the size of the legacy memory (meaning below 1 MB) that is required during an S3 resume. Before the Framework-based firmware transfers control to the OS, it has to transition from flat mode into real mode in case the OS supplies only a real-mode waking vector. This transition requires a certain amount of legacy memory. After getting the size of legacy memory below, the caller is responsible for allocating the legacy memory below 1 MB according to the size that is returned. The specific implementation of allocating the legacy memory is out of the scope of this specification. When EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() is called, the address of the legacy memory allocated above must be passed to it, in the LegacyMemoryAddress parameter. In practice however: - The S3Ready() function ignores the LegacyMemoryAddress completely. - No code in the edk2 tree calls EFI_ACPI_S3_SAVE_PROTOCOL.GetLegacyMemorySize(), ever. - All callers of this specific implementation of EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() in the edk2 tree pass a NULL LegacyMemoryAddress: BdsLibBootViaBootOption() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] For this reason, ASSERT() explicitly that LegacyGetS3MemorySize() is never called, and that the LegacyMemoryAddress parameter is always NULL. This fact is important to capture in the code, because in the End-of-Dxe callback, no LegacyMemoryAddress parameter can be taken. So let's make it clear that we actually don't even have any use for that parameter. This patch ports the identical change from IntelFrameworkModulePkg to OvmfPkg. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18033 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuBootOrderLib: recognize extra PCI root busesLaszlo Ersek2015-07-141-24/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OFW device path that QEMU exports in the "bootorder" fw_cfg file, for a device that is plugged into the main PCI root bus, is: /pci@i0cf8/... Whereas the same device plugged into the N'th extra root bus results in: /pci@i0cf8,N/pci-bridge@0/... (N is in hex.) Extend TranslatePciOfwNodes() so that it not assume a single PCI root; instead it parse the extra root bus serial number if present, and resolve it in the translation to the UEFI devpath fragment. Note that the "pci-bridge@0" node is a characteristic of QEMU's PXB device. It reflects the actual emulated PCI hierarchy. We don't parse it specifically in this patch, because it is automatically handled by the bridge sequence translator added recently in SVN rev 17385 (git commit feca17fa4b) -- "OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges". The macro EXAMINED_OFW_NODES need not be raised from 6. The longest OFW device paths that we wish to recognize under this new scheme comprise 5 nodes. The initial "extra root bus" OFW fragment, visible at the top, takes up 2 nodes, after which the longest device-specific patterns (IDE disk, IDE CD-ROM, ISA floppy, virtio-scsi disk) take 3 more nodes each. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17965 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuBootOrderLib: introduce ExtraRootBusMapLaszlo Ersek2015-07-143-0/+359
| | | | | | | | | | | | | | | | | | | | | | SeaBIOS requires the OpenFirmware device paths exported in the "bootorder" fw-cfg file to refer to extra (PXB) root buses by their relative positions (in increasing bus number order) rather than by actual bus numbers. However, OVMF's PCI host bridge / root bridge driver creates PciRoot(UID) device path nodes for extra PCI root buses with UID=bus_nr, not position. (These ACPI devpath UID values must, and do, match the UID values exposed in QEMU's ACPI payload, generated for PXB root buses.) Therefore the boot order matching logic will have to map extra root bus positions to bus numbers. Add a small group of utility functions to help with that. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17964 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PciHostBridgeDxe: shorten search for extra root busesLaszlo Ersek2015-07-142-1/+23
| | | | | | | | | | | | | | | QEMU provides an fw_cfg file called "etc/extra-pci-roots", containing a little-endian UINT64 value that exposes the number of extra root buses. We can use this value to terminate the scan as soon as we find the last extra root bus. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17963 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PciHostBridgeDxe: look for all root busesLaszlo Ersek2015-07-141-24/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this patch we assume that root bus number 0 is always there (same as before), and scan the rest of the extra root buses, up to and including 255. When an extra root bus is found, we install the PCI root bridge IO protocol for the previous root bus (which might be bus 0 or just the previous extra root bus). The root bridge protocol created thus will report the available bus number range [own bus number, next extra root bus number - 1] The LHS of this interval will be used for the root bus's own number, and the rest of the interval (which might encompass 0 additional elements too) can be used by the PCI bus driver to assign subordinate bus numbers from. (Subordinate buses are provided by PCI bridges that hang off the root bus in question.) For MMIO and IO space allocation, all the root buses share the original [0x8000_0000, 0xFFFF_FFFF] and [0x0, 0xFFFF] ranges, respectively. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17962 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PciHostBridgeDxe: eliminate PCI_HOST_BRIDGE_INSTANCE.RootBridgeNumberLaszlo Ersek2015-07-142-4/+1
| | | | | | | | | | | | | | This field was supposed to store the number of root buses created; however we don't need to keep that count persistently. After the entry point returns, nothing reads this field. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17961 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PciHostBridgeDxe: use private buffer in RootBridgeIoConfiguration()Laszlo Ersek2015-07-142-15/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On output, the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Configuration() function produces a pointer to a buffer of ACPI 2.0 resource descriptors: Resources A pointer to the ACPI 2.0 resource descriptors that describe the current configuration of this PCI root bridge. The storage for the ACPI 2.0 resource descriptors is allocated by this function. The caller must treat the return buffer as read-only data, and the buffer must not be freed by the caller. PciHostBridgeDxe currently provides this buffer in a structure with static storage duration. If multiple root bridges existed in parallel, the pointers returned by their Configuration() methods would point to the same static storage. A later Configuration() call would overwrite the storage pointed out by an earlier Configuration() call (which was possibly made for a different, but still alive, root bridge.) Fix this problem by embedding the configuration buffer in PCI_ROOT_BRIDGE_INSTANCE. While we're at it, correct some typos (Desp -> Desc), spell out a missing pack(1) pragma, and improve formatting. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17960 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PciHostBridgeDxe: release resources on driver entry failureLaszlo Ersek2015-07-141-3/+51
| | | | | | | | | | | | | | | | | | | | | | | | The entry point of the driver, InitializePciHostBridge(), leaks resources (and installed protocols) in the following cases: - The first root bridge protocol installation fails. In this case, the host bridge protocol is left installed, but the driver exits with an error. - The second or a later root bridge protocol installation fails. In this case, the host bridge protocol, and all prior root bridge protocols, are left installed, even though the driver exits with an error. Handle errors correctly: roll back / release / uninstall resources when aborting the driver. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17959 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PciHostBridgeDxe: factor out InitRootBridge() functionLaszlo Ersek2015-07-141-37/+89
| | | | | | | | | | | | | | This new function incorporates the current loop body found in the entry point function, InitializePciHostBridge(). It will be called once for each root bus discovered. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17958 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PciHostBridgeDxe: embed device path in private root bridge structLaszlo Ersek2015-07-142-25/+27
| | | | | | | | | | | | | | | | | | Currently we define a device path for each root bridge statically (for all one of them). Since we'll want to create a dynamic number of root bridges, replace the static device paths with a common template, embed the actual device path into the private root bridge structure, and distinguish the device paths from each other in the UID field (as required by ACPI). This patch is best viewed with "git show -b". Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17957 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PciHostBridgeDxe: kill RootBridgeNumber and RootBridgeAttributeLaszlo Ersek2015-07-141-10/+3
| | | | | | | | | | | | | There is no need to store these constants in dedicated static storage duration objects; we can simply open-code them, simplifying the code. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17956 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PciHostBridgeDxe: eliminate nominal support for multiple host bridgesLaszlo Ersek2015-07-142-76/+66
| | | | | | | | | | | | | | | | | | | | The entry point function of this driver, InitializePciHostBridge(), and the static storage duration objects it relies on, are speculatively generic -- they nominally support more than one host bridges, but (a) the code hardwires the number of host bridges as 1, (b) it's very unlikely that we'd ever like to raise that number (especially by open-coding it). So let's just remove the the nominal support, and simplify the code. This patch is best viewed with "git show -b". Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17955 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-02 12:06:50 +0000