summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)Author
2015-01-02OvmfPkg: QemuBootOrderLib: OFW-to-UEFI translation for virtio-mmioLaszlo Ersek
The TranslateMmioOfwNodes() function recognizes the following OpenFirmware device paths: virtio-blk: /virtio-mmio@000000000a003c00/disk@0,0 virtio-scsi disk: /virtio-mmio@000000000a003a00/channel@0/disk@2,3 virtio-net NIC: /virtio-mmio@000000000a003e00/ethernet-phy@0 The new translation can be enabled with the "PcdQemuBootOrderMmioTranslation" Feature PCD. This PCD also controls if the "survival policy" covers unselected boot options that start with the virtio-mmio VenHw() node. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16575 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: QemuBootOrderLib: widen ParseUnitAddressHexList() to UINT64Laszlo Ersek
The OpenFirmware device path nodes that QEMU generates for virtio-mmio transports contain 64-bit hexadecimal values (16 nibbles) -- the base addresses of the register blocks. In order to parse them soon, ParseUnitAddressHexList() must parse UINT64 values. Call sites need to be adapted, as expected. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16574 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: introduce VIRTIO_MMIO_TRANSPORT_GUIDLaszlo Ersek
Soon there will be more than one modules (in separate packages) that need to have an understanding about the GUID used in the VenHw() device path nodes that describe virtio-mmio transports. Define such a GUID explicitly. Preserve the current value (which happens to be the FILE_GUID of ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf) for compatibility with external users. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16572 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: QemuBootOrderLib: featurize PCI-like device path translationLaszlo Ersek
In preparation for adding OpenFirmware-to-UEFI translation for "MMIO-like" OFW device path fragments, let's turn the currently exclusive "PCI-like" translation into "just one" of the possible translations. - Rename TranslateOfwNodes() to TranslatePciOfwNodes(), because it is tightly coupled to "PCI-like" translations. - Rename REQUIRED_OFW_NODES to REQUIRED_PCI_OFW_NODES, because this macro is specific to TranslatePciOfwNodes(). - Introduce a new wrapper function under the original TranslateOfwNodes() name. This function is supposed to try translations in some order until a specific translation returns a status different from RETURN_UNSUPPORTED. - Introduce a new Feature PCD that controls whether PCI translation is attempted at all. - The boot option "survival policy" in BootOrderComplete() must take into account if the user was able to select PCI-like boot options. If the user had no such possibility (because the Feature PCD was off for PCI-like translation), then we ought to keep any such unselected boot options. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16571 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: extract QemuBootOrderLibLaszlo Ersek
and rebase OvmfPkg's PlatformBdsLib on the standalone library. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16570 6f19259b-4bc3-4df7-8a09-765794883524
2014-12-19OvmfPkg: enable the IPv6 supportGary Lin
There are several network stack drivers in MdeModulePkg or NetworkPkg. Currently, we only use the drivers from MdeModulePkg which only provides the IPv4 support. This commit adds the IPv6 drivers in NetworkPkg into OVMF. Here is the table of drivers from Laszlo. currently included related driver add or replace from MdeModulePkg in NetworkPkg from NetworkPkg ------------------ -------------- --------------- SnpDxe n/a n/a DpcDxe n/a n/a MnpDxe n/a n/a VlanConfigDxe n/a n/a ArpDxe n/a n/a Dhcp4Dxe Dhcp6Dxe add Ip4ConfigDxe Ip6Dxe add Ip4Dxe Ip6Dxe add Mtftp4Dxe Mtftp6Dxe add Tcp4Dxe TcpDxe replace Udp4Dxe Udp6Dxe add UefiPxeBcDxe UefiPxeBcDxe replace IScsiDxe IScsiDxe replace Since the TcpDxe, UefiPxeBcDxe, and IScsiDxe drivers in NetworkPkg also support IPv4, we replace the ones in MdeModulePkg. To enable the IPv6 support, build OVMF with "-D NETWORK_IP6_ENABLE". A special case is NetworkPkg/IScsiDxe. It requires openssl. For convenience, NetworkPkg/IScsiDxe is enabled only if both IPv6 and SecureBoot are enabled. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> [lersek@redhat.com: typo fix in commit message; specil -> special] Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16543 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-21OvmfPkg: CsmSupportLib: depend on OvmfPkg.dec explicitlyLaszlo Ersek
SVN r16375 (git commit 72a11001, "OvmfPkg: CsmSupportLib: Set/use platform specific legacy interrupt device") added the gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId PCD to CsmSupportLib. Since that "namespace" GUID is declared in OvmfPkg/OvmfPkg.dec, and we've not used anything from OvmfPkg/OvmfPkg.dec in CsmSupportLib.inf thus far, this is a new [Packages] dependency and must be named. 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@16414 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-20OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration explicitLaszlo Ersek
The ACPI payload that OVMF downloads from QEMU via fw_cfg depends on the PCI enumaration and resource assignment performed by MdeModulePkg/Bus/Pci/PciBusDxe. Namely, although the ACPI payload is pre-generated in qemu during machine initialization, in main() [vl.c] qemu_run_machine_init_done_notifiers() pc_guest_info_machine_done() [hw/i386/pc.c] acpi_setup() [hw/i386/acpi-build.c] acpi_build() acpi_add_rom_blob() rom_add_blob(... acpi_build_update ...) [hw/core/loader.c] fw_cfg_add_file_callback() [hw/nvram/fw_cfg.c] the ACPI data is rebuilt at the first time any of the related fw_cfg files are read, through the acpi_build_update() fw_cfg read-callback function: fw_cfg_read() [hw/nvram/fw_cfg.c] acpi_build_update() [hw/i386/acpi-build.c] acpi_build() (See qemu commit d87072ceeccf4f84a64d4bc59124bcd64286c070 and its containing series.) For this reason we must not dispatch AcpiPlatformDxe before PciBusDxe completes the enumeration. Luckily, the PI Specification 1.3 defines EFI_PCI_ENUMERATION_COMPLETE_GUID in Volume 5, "10.9 End of PCI Enumeration Overview", as an indicia to inform the platform when the PCI enumeration process has completed. PciBusDxe installs this protocol at the end of the PciEnumerator() function. Let's add this GUID to the Depex section of AcpiPlatformDxe, in order to state the dependency explicitly. On Xen, and on older QEMU where the linker/loader fw_cfg interface is unavailable, this introduces a harmless ordering constraint -- we'll always include PciBusDxe in OVMF, so the dependency will always be satisfied. I tested this change as follows: - I dumped the ACPI tables in a Fedora 20 guest, before and after the change, and compared them. The only thing that actually changed was the FACS address. (Which I promptly tested with S3 suspend/resume.) Plus, of course, the FACP checksum changed, because the FACP links the FACS. - Tested S3 in my Windows Server 2008 R2 and Windows Server 2012 R2 guests. 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@16411 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-19OvmfPkg: Fix build failure with gcc44, gcc45Scott Duplichan
OvmfPkg/XenBusDxe/XenHypercall.h:19:31: error: redefinition of typedef 'XENBUS_DEVICE' OvmfPkg/XenBusDxe/XenBusDxe.h:86:31: note: previous declaration of 'XENBUS_DEVICE' was here Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Acked-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16408 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-17OvmfPkg: PlatformBdsLib: Dynamic PCI Interrupt Line register setupGabriel Somlo
Remove hard-coded list of PCI devices for which the Interrupt Line register is initialized. Instead, provide a "visitor" function to initialize the register only for present and applicable PCI devices. At this time, we match the behavior of SeaBIOS (file src/fw/pciinit.c, functions *_pci_slot_get_irq() and "map the interrupt" block from pci_bios_init_device()). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16398 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg/XenBusDxe: Fix a nasm warning about instruction not lockable.Anthony PERARD
The fix, having "lock" and the locked instruction on the same line in the source. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16394 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg/XenPvBlkDxe: fix VS2010 build failuresScott Duplichan
This patch contain type casts and replace one * operation by a MultU64x32() call. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16393 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg/XenBusDxe: fix VS2010 build failuresScott Duplichan
This patch contain only type cast. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Acked-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16392 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg/XenBusDxe: Fix some types.Anthony PERARD
This patch replace some types in GrantTable and the argument Index of XenHypercallHvmGetParam to what the types should be. This avoid to have type cast in code. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16391 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg/XenBusDxe: In XenStore, replace type of Len from UINTN to UINT32.Anthony PERARD
Since a message to XenStore have a lenght of type UINT32, have XenStore.c deal only with UINT32 instead of a mixmatch with UINTN. This patch replaces the type of Len in WRITE_REQUEST and the type of the argument Len of XenStoreWriteStore and XenStoreReadStore. This patch should avoid to have type cast were it does not make sense to have them. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16390 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: VirtioScsiDxe: drop 64-bit shift in PopulateRequest() (VS2010)Scott Duplichan
"Lun" has type UINT64 in this function. The result of the expression (UINT8) ((Lun >> 8) | 0x40) depends only on bits [15:8] of "Lun", therefore we can cast "Lun" to UINT32 before shifting it. This eliminates an intrinsic when building with VS2010 for Ia32 / NOOPT. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> [lersek@redhat.com: added commit message] 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@16386 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: QemuVideoDxe: the VBE shim needs no 64-bit shifts (VS2010)Scott Duplichan
The SegmentC local variable has type EFI_PHYSICAL_ADDRESS for (justified) style reasons. However, the 64-bit bit-shifts that it undergoes result in intrinsic calls when built with VS2010 for Ia32 / NOOPT. The concrete value of SegmentC, 0xC0000, and the results of the bitops that are based on it, are statically computeable. Cast SegmentC to UINT32 before subjecting it to bitwise operations; we can see in advance that this won't lead to range loss. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> [lersek@redhat.com: dropped now superfluous outermost parens; commit msg] 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@16385 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: flash driver: drop needlessly wide multiplication (VS2010)Scott Duplichan
The current types of subexpressions used in QemuFlashPtr() are as follows. (We also show the types of "larger" subexpressions, according to operator binding.) mFlashBase + (Lba * mFdBlockSize) + Offset ^ ^ ^ ^ | | | | (UINT8*) EFI_LBA UINTN UINTN (UINT64) --------------------------------- ------ (UINT8*) UINTN ------------------------------------------ (UINT8*) When building with VS2010 for Ia32 / NOOPT, the 64-by-32 bit multiplication is translated to an intrinsic, which is not allowed in edk2. Recognize that "Lba" is always bounded by "mFdBlockCount" (an UINTN) here -- all callers of QemuFlashPtr() ensure that. In addition, the flash chip in question is always under 4GB, which is why we can address it at all on Ia32. Narrow "Lba" to UINTN, without any loss of range. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> [commit message by lersek@redhat.com] 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@16384 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPg: flash driver: drop gratuitous 64-by-32 bit divisions (VS2010)Laszlo Ersek
In the InitializeVariableFvHeader() function, all three of "Offset", "Start" and "BlockSize" have type UINTN. Therefore the (Offset / BlockSize) and (Start / BlockSize) divisions can be compiled on all platforms without intrinsics. In the current expressions (EFI_LBA) Offset / BlockSize (EFI_LBA) Start / BlockSize "Offset" and "Start" are cast to UINT64 (== EFI_LBA), which leads to 64-by-32 bit divisions on Ia32, breaking the VS2010 / NOOPT / Ia32 build. The simplest way to fix them is to realize we don't need casts at all. (The prototypes of QemuFlashEraseBlock() and QemuFlashWrite() are visible via "QemuFlash.h", and they will easily take our UINTN quotients as UINT64.) Suggested-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@16383 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPg: flash driver: fix type of EFI_SIZE_TO_PAGES argument (VS2010)Laszlo Ersek
The MarkMemoryRangeForRuntimeAccess() function passes the Length parameter (of type UINT64) to the macro EFI_SIZE_TO_PAGES(). When building for the Ia32 platform, this violates the interface contract of the macro: [...] Passing in a parameter that is larger than UINTN may produce unexpected results. In addition, it trips up compilation by VS2010 for the Ia32 platform and the NOOPT target -- it generates calls to intrinsics, which are not allowed in edk2. Fix both issues with the following steps: (1) Demote the Length parameter of MarkMemoryRangeForRuntimeAccess() to UINTN. Even a UINT32 value is plenty for representing the size of the flash chip holding the variable store. Length parameter is used in the following contexts: - passed to gDS->RemoveMemorySpace() -- takes an UINT64 - passed to gDS->AddMemorySpace() -- ditto - passed to EFI_SIZE_TO_PAGES() -- requires an UINTN. This also guarantees that the return type of EFI_SIZE_TO_PAGES() will be UINTN, hence we can drop the outer cast. (2) The only caller of MarkMemoryRangeForRuntimeAccess() is FvbInitialize(). The latter function populates the local Length variable (passed to MarkMemoryRangeForRuntimeAccess()) from PcdGet32(PcdOvmfFirmwareFdSize). Therefore we can simply demote the local variable to UINTN in this function as well. - There's only one other use of Length in FvbInitialize(): it is passed to GetFvbInfo(). GetFvbInfo() takes an UINT64, so passing an UINTN is fine. Suggested-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@16382 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initializationGabriel Somlo
Merge PciInitialization() and AcpiInitialization() into a single function, PciAcpiInitialization(), and use a PCD set during PEI to detect the underlying platform type (PIIX4 or Q35/MCH) and therefore the addresses of the registers to be initialized. Add LNK[A-H] routing target initialization for the Q35 platform. Additionally, initialize PCI_INTERRUPT_LINE registers for the typical set of PCI devices included by QEMU with the Q35 machine type. The corresponding PIIX4 initialization of PCI_INTERRUPT_LINE registers is cleaned up and the list of PIIX4 PCI devices updated to the list typically included with QEMU. NOTE: The list of PCI devices for which we initialize PCI_INTERRUPT_LINE is hard-coded, and, depending on how QEMU devices are configured on the command line, may miss some devices, or (harmlessly) attempt to initialize devices which are not present in the system. A subsequent patch will replace this hard-coded list with a mechanism to correctly initialize PCI_INTERRUPT_LINE for applicable present PCI devices only. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16379 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: AcpiTimerLib: Switch additional stages to PCD-based Dxe instanceGabriel Somlo
Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against a valid, non-asserting version of PcdLib, then switch them over to using the "Dxe" instance of AcpiTimerLib (instead of the "Base" version). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@16378 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIMGabriel Somlo
Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may utilize global variables, use the "Base" AcpiTimerLib instance (instead of BaseRom) to take advantage of the improved efficiency of storing the timer register IO address in a global variable. This leaves only SEC using the BaseRomAcpiTimerLib instance. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@16377 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instancesGabriel Somlo
Remove local power management register access macros in favor of factored-out ones in OvmfPkg/Include/OvmfPlatforms.h Next, AcpiTimerLib is split out into three instances, for use during various stages: - BaseRom: used during SEC, PEI_CORE, and PEIM; - Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER; - Base: used by default during all other stages. Most of the code remains in AcpiTimerLib.c, to be shared by all instances. The two platform-dependent methods (constructor and InternalAcpiGetTimerTick) are provided separately by source files specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c. Since pre-DXE stages can't rely on storing data in global variables, methods specific to the "BaseRom" instance will call platform detection macros each time they're invoked. The "Base" instance calls platform detection macros only from its constructor, and caches the address required by InternalAcpiTimerTick in a global variable. The "Dxe" instance is very similar to "Base", except no platform detection macros are called at all; instead, the platform type is read via a dynamic PCD set from PlatformPei. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: CsmSupportLib: Set/use platform specific legacy interrupt deviceGabriel Somlo
Use a PCD set from PEI to determine the legacy interrupt device number appropriate for the underlying platform type during protocol initialization. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16375 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: Add PCD for Host Bridge dev. ID (PcdOvmfHostBridgePciDevId)Gabriel Somlo
Set from PEI, this PCD allows subsequent stages (specifically DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform type (e.g. PIIX4 or Q35/MCH) without the need to further query the Host Bridge for its Device ID. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16374 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: PlatformPei: Platform specific ACPI power management setupGabriel Somlo
Set up ACPI power management using registers determined based on the underlying (PIIX4 or Q35/MCH) platform type. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16373 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: Factor out platform detection (q35 vs. piix4)Gabriel Somlo
Introduce macros to detect the underlying platform and access its ACPI power management registers, based on querying the host bridge device ID. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16372 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-12OvmfPkg/XenPvBlkDxe: Don't include system inttypes.hJordan Justen
EDK II code should not include system include files. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16341 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-08OvmfPkg XenBusDxe: Convert X64/TestAndClearBit.asm to NASMAnthony PERARD
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/TestAndClearBit.asm to X64/TestAndClearBit.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16319 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-08OvmfPkg XenBusDxe: Convert X64/InterlockedCompareExchange16.asm to NASMAnthony PERARD
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/InterlockedCompareExchange16.asm to X64/InterlockedCompareExchange16.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16318 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-08OvmfPkg XenBusDxe: Convert X64/hypercall.asm to NASMAnthony PERARD
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/hypercall.asm to X64/hypercall.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16317 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-08OvmfPkg XenBusDxe: Convert Ia32/TestAndClearBit.asm to NASMAnthony PERARD
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/TestAndClearBit.asm to Ia32/TestAndClearBit.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16316 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-08OvmfPkg XenBusDxe: Convert Ia32/InterlockedCompareExchange16.asm to NASMAnthony PERARD
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/InterlockedCompareExchange16.asm to Ia32/InterlockedCompareExchange16.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16315 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-08OvmfPkg XenBusDxe: Convert Ia32/hypercall.asm to NASMAnthony PERARD
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/hypercall.asm to Ia32/hypercall.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16314 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: set video resolution of text setup to 640x480Laszlo Ersek
On a physical screen such a low graphics resolution would lead to huge glyphs (the text resolution is 80x25, centered, with 8x19 pixel glyphs). But in a virtual machine it just saves screen real estate on the client, by removing the black bands. 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@16311 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: drop custom boot timeout, revert to IntelFrameworkModulePkg'sLaszlo Ersek
PlatformBdsEnterFrontPage() already implements a keypress wait (for entering the setup utility at boot) with a nice progress bar, only OVMF has not been using it. Removing our custom code and utilizing PlatformBdsEnterFrontPage()'s builtin wait has the following benefits: - It simplifies OVMF's BDS code. - Because now we call PlatformBdsEnterFrontPage() unconditionally, it actually has a chance to look at the EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit of the "OsIndications" variable, improving compliance with the UEFI specification. References: - https://bugzilla.redhat.com/show_bug.cgi?id=1153927 - http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10487 - The progress bar looks nice. (And it keeps the earlier behavior intact, when the user presses a key on the TianoCore splash screen.) In any case, we set the timeout to 0 (which doesn't show the progress bar and proceeds to the boot options immediately) in order to keep the boot time down. 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@16310 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: drop superfluous "connect first boot option" logicLaszlo Ersek
This is again obviated by our earlier BdsLibConnectAll() call. 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@16309 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: optimize second argument in PlatformBdsEnterFrontPage() callLaszlo Ersek
The second parameter of said function is "ConnectAllHappened", and if set to TRUE, the function sets "gConnectAllHappened" to TRUE. This global variable in turn controls whether Intel BDS code *itself* calls BdsLibConnectAllDriversToAllControllers() in various places -- if the indicator is TRUE, then the "connect all" is assumed to have been performed, and Intel BDS doesn't do it itself. OVMF should pass TRUE as "ConnectAllHappened", because a few lines before our call to PlatformBdsEnterFrontPage(), we already connect everything with BdsLibConnectAll(), which includes the effects of BdsLibConnectAllDriversToAllControllers(): PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] BdsLibConnectAll() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConnect.c] BdsLibConnectAllDriversToAllControllers() PlatformBdsEnterFrontPage() [IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c] 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@16308 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: don't overwrite the BDS Front Page timeoutLaszlo Ersek
The PlatformBdsEnterFrontPage() function's first parameter, "TimeoutDefault", determines the behavior of the setup utility: - If (TimeoutDefault == 0), then the usual boot order is to be acted upon immediately. - If (TimeoutDefault == 0xFFFF), then the setup utility is entered unconditionally. - If (0 < TimeoutDefault && TimeoutDefault < 0xFFFF), then the PlatformBdsEnterFrontPage() function displays a progress bar, waiting for TimeoutDefault seconds. If the user presses a key, then the setup utility is entered, otherwise the normal boot option processing takes place. The TimeoutDefault parameter is supposed to be set from gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut which has the following (matching) documentation in "IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec": The number of seconds that the firmware will wait before initiating the original default boot selection. A value of 0 indicates that the default boot selection is to be initiated immediately on boot. The value of 0xFFFF then firmware will wait for user input before booting. OVMF does this actually -- see the Timeout variable in PlatformBdsPolicyBehavior() -- but right before calling PlatformBdsEnterFrontPage(), OVMF hardwires TimeoutDefault to 0xFFFF. This has been acceptable until now, because OVMF implements its own "wait for keypress at the splash screen" logic in PlatformBdsPolicyBehavior(), completely avoiding the progress bar mentioned above. OVMF only calls PlatformBdsEnterFrontPage() when the user presses a key during its own "splash screen wait", and *then* it indeed makes sense to enter the setup utility unconditionally. However, even that way, the Timeout = 0xffff; assignment is superfluous, because 0xFFFF is already the default value of PcdPlatformBootTimeOut in "IntelFrameworkModulePkg.dec", and OvmfPkg doesn't override it in its DSC files. 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@16307 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: drop useless return statementLaszlo Ersek
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@16306 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: remove dead call to PlatformBdsEnterFrontPage()Laszlo Ersek
This call has been dead since the conception of OvmfPkg (git commit 49ba9447 / SVN r8398), and only confuses readers -- let's remove it. 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@16305 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31EDK II Contributions.txt: Update patch format informationJordan Justen
Update to show what the patch looks like in email form. NOTE: This does not modify the wording of the "TianoCore Contribution Agreement 1.0" section Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16297 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg/XenBusDxe: Fix initialisation of gXenBusDevicePathTemplateAnthony PERARD
.. to avoid the use .member = value syntax as VS does not support it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16296 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg/XenBusDxe: Fix initialisation of gXenBusPrivateDataAnthony PERARD
.. to avoid the use .member = value syntax as VS does not support it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16295 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg/Xen*: Pass struct XENSTORE_TRANSACTION argument as a pointerAnthony PERARD
As EDK II does not allow calls with a struct. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16294 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg/Include/...Xen: Convert __i386__/__x86_64__ to MDE_CPU_IA32/MDE_CPU_X64.Anthony PERARD
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16293 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg Sec: Convert X64/SecEntry.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/SecEntry.asm to X64/SecEntry.nasm Note: Manually collapsed .inf sources 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@16292 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg Sec: Convert Ia32/SecEntry.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/SecEntry.asm to Ia32/SecEntry.nasm Note: Manually collapsed .inf sources 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@16291 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg QemuFwCfgLib: Convert X64/IoLibExAsm.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/IoLibExAsm.asm to X64/IoLibExAsm.nasm 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@16290 6f19259b-4bc3-4df7-8a09-765794883524