summaryrefslogtreecommitdiff
path: root/OvmfPkg/Library
AgeCommit message (Collapse)Author
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-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
2014-10-31OvmfPkg QemuFwCfgLib: Convert Ia32/IoLibExAsm.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/IoLibExAsm.asm to Ia32/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@16289 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg LoadLinuxLib: Convert X64/JumpToKernel.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/JumpToKernel.asm to X64/JumpToKernel.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@16288 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg LoadLinuxLib: Convert Ia32/JumpToKernel.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/JumpToKernel.asm to Ia32/JumpToKernel.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@16287 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-25OvmfPkg: Fix VS2005 build warningsJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16171 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-09OvmfPkg: AcpiTimerLib: Access power mgmt regs based on host bridge typeGabriel Somlo
Pick the appropriate bus:dev.fn for accessing ACPI power management registers (00:01.3 on PIIX4 vs. 00:1f.0 on Q35) based on the device ID of the host bridge (assumed always present at 00:00.0). With this patch, OVMF can boot QEMU's "-machine q35" x86 machine type. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> 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@16066 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-13Fix VS2013 build failure.Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15795 6f19259b-4bc3-4df7-8a09-765794883524
2014-06-19OvmgPkg: QemuFwCfgLib: export QEMU_FW_CFG_FNAME_SIZELaszlo Ersek
Names of firmware configuration files always take 56 bytes (including at least one terminating NUL byte). Expose this constant to all consumers of QemuFwCfgLib because further interfaces may depend on 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@15571 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-31OvmfPkg: add a catch-all match for PCI devices in the OpenFirmware pathPaolo Bonzini
In many cases, the second node in /pci@i0cf8/XYZ@DD,FF node is enough to match a UEFI device path; a typical cases is a NIC that is assigned from the host to the guest. Add a catch-all case for PCI devices, and reuse it for NICs since it works well for those too. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15422 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-13OvmfPkg: BDS: QemuBootOrder: don't leak unreferenced boot optionsLaszlo Ersek
The Boot#### variables that have become unreferenced in the new BootOrder variable won't ever be automatically reused for booting. They are "unreachable" resources that take up room in the variable store. Make an effort to remove them. This should plug the leak which, given sufficient reboots, exhausts the variable store with stale Boot#### variables and renders the VM unbootable. Reported-by: Michael Chang <mchang@suse.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@15327 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-13OvmfPkg: BDS: remove historic (now defunct) boot mode hackLaszlo Ersek
When PI can distinguish the "full config" boot mode from "assume no changes", then the following BDS logic is correct: if BootMode == BOOT_WITH_FULL_CONFIGURATION: // // connect all devices // create & append each default boot option that's missing // BdsLibConnectAll BdsLibEnumerateAllBootOption else if BootMode == BOOT_ASSUMING_NO_CONFIGURATION_CHANGES: // // just stick with current BootOrder and the Boot#### variables // referenced by it // In theory, the first branch is intended to run infrequently, and the "assume no changes" branch should run most of the time. However, some platforms can't tell these two boot modes apart. The following substitute had been introduced: // // Technically, always assume "full config", but the BootMode HOB is // actually meaningless wrt. to "full config" or "assume no changes". // ASSERT (BootMode == BOOT_WITH_FULL_CONFIGURATION); // // Key off the existence of BootOrder. Try to prepare an in-memory list // of boot options, based on BootOrder and the referenced Boot#### // variables. // Status = BdsLibBuildOptionFromVar() // // If that succeeded, we'll treat it as "assume no changes". If it // failed (*only* if it failed), we'll build default boot options, // calling it "full config": // if EFI_ERROR(Status): BdsLibConnectAll() BdsLibEnumerateAllBootOption(BootOptionList) What we have now in OVMF is a mixture of the hack, and the behavior that's theoretically correct for "full config": - We assert "full config" -- this is OK. - We call "connect all" and "enumerate all" deliberately -- this is OK too. It matches "full config" which we assert. - However, we also have the hack in place, which had been meant as an alternative. In order to clean this up, we either need to restore the hack to its original form (ie. comment out the unconditional calls again), or we ought to remove the hack altogether. The unconditional "connect all" + "enumerate all" calls are the correct approach for OVMF, because we want, in fact, to start with "full config". The QEMU boot order specification and the set of emulated devices might change "out of band", which excludes "assume no changes". In other words, removing the hack corresponds to the "real production" case that the comment hints at. Because SetBootOrderFromQemu() may change the BootOrder NvVar, we must preserve the BdsLibBuildOptionFromVar() function call, in order to refresh the in-memory list with the new boot priorities. (The last step of BdsLibEnumerateAllBootOption() is such a call too.) 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@15326 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: implement LockBoxLibLaszlo Ersek
The S3 suspend/resume infrastructure depends on the LockBox library class. The edk2 tree currently contains Null and SMM instances. The Null instance is useless, and the SMM instance would require SMM emulation by including the SMM core and adding several new drivers, which is deemed too complex. Hence add a simple LockBoxLib instance for OVMF. jordan.l.justen@intel.com: * use PCDs instead of EmuNvramLib - clear memory in PlatformPei on non S3 boots * allocate NVS memory and store a pointer to that memory - reduces memory use at fixed locations Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> 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@15301 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg QemuFwCfgLib: determine if S3 support is explicitly enabledLaszlo Ersek
Such a packaged query function will come in handy in the following patches. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: check for enabled rather than disabled] 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@15292 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-09OvmfPkg: QemuBootOrder: initialize IsFinal variable to make MSVC happyMauro Faccenda
The BOOLEAN IsFinal variable initialization isn't properly seen by MSVC. To make it compile OVMF the variable needs to be initialized. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Mauro Faccenda <faccenda@gmail.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@15214 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-29OvmfPkg: QemuBootOrder: handle QEMU's "-boot strict=on" optionLaszlo Ersek
When this option is passed to qemu, it appends the word HALT to the "bootorder" fw_cfg file, as last entry. For example, /pci@i0cf8/ethernet@3/ethernet-phy@0 /pci@i0cf8/scsi@4/disk@0,0 HALT The option's purpose is to prevent SeaBIOS from booting from devices that have not been specified explicitly (with bootindex=N device properties nor -boot options). When SeaBIOS sees HALT, it doesn't proceed to boot from default locations (after boot fails from all of the listed locations). The HALT string currently causes OVMF to reject the entire "bootorder" fw_cfg contents, with "parse error". This is not good, because since a recent libvirt commit, libvirt unconditionally passes "-boot strict=on" to qemu. Consequently, the boot order logic in QemuBootOrder.c has stopped working for libvirt users. OVMF's SetBootOrderFromQemu() function actually implements the idea behind "-boot strict=on": it drops all boot options not in the fw_cfg list. (*) Therefore, let's recognize HALT, and just do what we've been doing all along. (*) Except the UEFI shell, according to the survival policy in BootOrderComplete(), but the memory mapped UEFI shell is not expressible via fw_cfg anyway, and its preservation has been requested on edk2-devel. Hence it's a good boot option to keep in any case. 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@15197 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-03OvmfPkg: QemuFwCfgLib: implement for SECLaszlo Ersek
The QemuFwCfgSecLib library instance - is stateless, - has no library constructor, - is available to SEC client code, - must be queried with QemuFwCfgIsAvailable() before use, - is restricted to SEC in order to limit the explicit querying requirement. (There is no current user.) 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@15046 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-03OvmfPkg: QemuFwCfgLib: extract stateful implementationLaszlo Ersek
The current implementation of QemuFwCfgLib is: - stateful - implicitly initialized in the library constructor. OVMF's SEC runs from read-only memory/flash. When the library is linked into a SEC binary (which currently never happens), the "mQemuFwCfgSupported" global variable becomes read-only, making the library non-functional. Extract the stateful, implicitly initialized library implementation into a separate file, making room for a stateless, explicitly queried implementation that's usable in SEC. Restrict the stateful implementation to the current, non-SEC clients. 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@15045 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-03OvmfPkg: QemuFwCfgLib: introduce InternalQemuFwCfgIsAvailable()Laszlo Ersek
This internal function allows separation of library-internal and for-clients external availability of fw_cfg. The interface contract of QemuFwCfgIsAvailable() is changed so that now it may modify fw_cfg state. All current users are compliant with the new contract. 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@15044 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-26OvmfPkg: QemuFwCfgLib: drop bogus dependency on UefiBootServicesTableLibLaszlo 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@15024 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/Virtio: Removed VirtioReadDevice() / VirtIoWriteDevice() functionsOlivier Martin
These functions did not provide much more than the new protocol functions VIRTIO_DEVICE_PROTOCOL.ReadDevice() / VIRTIO_DEVICE_PROTOCOL.WriteDevice(). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14968 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg: Make the VirtIo devices use the new VIRTIO_DEVICE_PROTOCOLOlivier Martin
This change replaces the accesses to the PCI bus from the Block, Scsi and Net drivers by the use of the new VIRTIO_DEVICE_PROTOCOL protocol that abstracts the transport layer. It means these drivers can be used on PCI and MMIO transport layer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - VirtioFlush(): update comment block in VirtioLib.[hc]; error code is propagated from VirtIo->SetQueueNotify(). - VirtioBlkInit(): jump to Failed label if SetPageSize() fails - VirtioBlkInit(): fixup comment, and add error handling, near SetQueueNum() call - VirtioBlkDriverBindingStart(): remove redundant (always false) check for a subsystem device ID different from VIRTIO_SUBSYSTEM_BLOCK_DEVICE; VirtioBlkDriverBindingSupported() handles it already - VirtioNetGetFeatures(): update stale comment block - VirtioNetGetFeatures(): retrieve MAC address byte for byte (open-coded loop) - VirtioNetDriverBindingStart(): remove redundant (always false) check for a subsystem device ID different from VIRTIO_SUBSYSTEM_NETWORK_CARD; VirtioNetDriverBindingSupported() handles it already - VirtioNetInitRing(): call SetQueueNum() and SetQueueAlign() for proper MMIO operation - VirtioNetInitialize(): fix destination error label for when SetPageSize() fails - VirtioScsi.c: fix comment block of VIRTIO_CFG_WRITE()/VIRTIO_CFG_READ() - VirtioScsiInit(): fix destination error label for when SetPageSize() fails - VirtioScsiInit(): call SetQueueNum() and SetQueueAlign() for proper MMIO operation 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@14966 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo ↵Olivier Martin
Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency 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@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg/BdsPlatform: don't restore NvVars from disk when flash is presentLaszlo Ersek
QemuFlashFvbServicesRuntimeDxe provides actual persistent storage for non-volatile variables. When it is active, any on-disk NvVars file counts as a stale source of variables -- hence don't load these files in BDS. This also allows Secure Boot settings (eg. enrolled keys) to survive cold VM reboots. 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@14844 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-24OvmfPkg: EFI handover flags are in Bp->hdr.xloadflagsMatt Fleming
LoadLinux() is looking at the wrong field for the kernel's EFI handover protocol flags. It's not currently possible for JumpToUefiKernel() to ever be called (even accidentally) because BIT2 and BIT3 of Bp->hdr.load_flags are never set in modern kernels, which means that control is always transferred to the kernel via the legacy entry point. Look at the correct field so that the EFI handover protocol is used whenever it's available. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: David Woodhouse <David.Woodhouse@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Borislav Petkov <bp@suse.de> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14721 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: keep some boot options that have not been selectedLaszlo Ersek
Some of the active boot options that have not been selected over fw_cfg should be preserved at the end of the boot order. For now we're adding back everything that starts with neither PciRoot() nor HD(). This includes the UEFI shell, memory-mapped from the firmware image. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14668 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: mark UEFI boot options selected by fw_cfgLaszlo Ersek
This will allow us to identify those UEFI boot options (while keeping their relative order) that have *not* been selected by fw_cfg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14667 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: collect active UEFI boot options in advanceLaszlo Ersek
In preparation for the next patch, collect active UEFI boot options in advance into a new array. Rebase the current inner loop (the matching loop) to this array. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> [jordan.l.justen@intel.com: initialize *ActiveOption for GCC IA32 warning] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14666 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: expand relative device paths in UEFI boot optionsLaszlo Ersek
The prefix matching logic in Match() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options to specify full (absolute) device paths. However, partial (relative) device paths starting with a HD() node are valid for booting. By not recognizing them, QemuBootOrder.c misses (and deletes) valid boot options that would otherwise match the user's preference. Just like BdsLibBootViaBootOption() expands such paths with the BdsExpandPartitionPartialDevicePathToFull() function for booting, do the same in QemuBootOrder.c for prefix matching. This moves the very first call to BdsExpandPartitionPartialDevicePathToFull() to an earlier point. The following call tree explains it: BdsEntry() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c] PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] SetBootOrderFromQemu() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] Match() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] BdsBootDeviceSelect() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c] BdsLibBootViaBootOption() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] This should be fine, for two reasons: - the new, earlier call is still under BdsEntry(), - BdsExpandPartitionPartialDevicePathToFull() expects to be called repeatedly, even with the same set of HD() device paths. This function implements its own caching for device paths, likely for performance reasons. That fits this patch well because whatever device paths we expand under PlatformBdsPolicyBehavior() can be quickly looked up in BdsBootDeviceSelect(), so no work (ie. BdsLibConnectAllDriversToAllControllers()) should be wasted. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14665 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-30OvmfPkg NvVarsFileLib: Set NvVars variable after writing vars fileJordan Justen
The volatile 'NvVars' variable indicates that the variables do not need to be loaded from the file again. After we write the variables out to the file, there is clearly no need to load them back from the file. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14613 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-23OvmfPkg: Virtio: load used ring element strictly after loading used indexLaszlo Ersek
Enforce in-order execution of these steps even on not sequentially consistent architectures, as discussed in [1]. These changes should be unnecessary on x86 (the only architecture OVMF currently supports), but they align the OVMF virtio code with the virtio specification and could be necessary for future OVMF ports. [1] http://lists.linuxfoundation.org/pipermail/virtualization/2013-June/024547.html Suggested-by: Stefan Hajnoczi <stefanha@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14601 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-19OvmfPkg ResetSystemLib: Fix VS build errorRuiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <Ruiyu.ni@Intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14557 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-18OvmfPkg: allocate the EFI memory map for Linux as Loader DataLaszlo Ersek
In Linux, efi_memblock_x86_reserve_range() and efi_reserve_boot_services() expect that whoever allocates the EFI memmap allocates it in Loader Data type memory. Linux's own exit_boot()-->low_alloc() complies, but SetupLinuxMemmap() in LoadLinuxLib doesn't. The memory type discrepancy leads to efi_memblock_x86_reserve_range() and efi_reserve_boot_services() both trying to reserve the range backing the memmap, resulting in memmap entry truncation in efi_reserve_boot_services(). This fix also makes this allocation consistent with all other persistent allocations in "OvmfPkg/Library/LoadLinuxLib/Linux.c". Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reported-and-tested-by: Borislav Petkov <bp@suse.de> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14555 6f19259b-4bc3-4df7-8a09-765794883524
2013-07-26Update all the code to consume the ConvertDevicePathToText, ↵Ruiyu Ni
ConvertDevicePathNodeToText, ConvertTextToDevicePath and ConvertTextToDeviceNode APIs in DevicePathLib. Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com> Reviewed-by: Elvin Li <elvin.li@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14505 6f19259b-4bc3-4df7-8a09-765794883524
2013-07-18OvmfPkg ResetSystemLib: Fix shutdown via UEFI runtime servicesJordan Justen
When the PM base address was moved from 0x400 to 0xb000, this code was missed. This prevented shutdown's via the UEFI system call from working. (For example, at the EFI shell prompt: reset -s) We now use gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress which is currently set at 0xb000. 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@14492 6f19259b-4bc3-4df7-8a09-765794883524
2013-07-16Fix IA32 build failure.Ruiyu Ni
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14472 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-28OvmfPkg/SerializeVariablesLib: ignore secure variable restore errorsjljusten
OvmfPkg's file-based NvVar storage is read back as follows at boot (all paths under OvmfPkg/Library/): PlatformBdsPolicyBehavior() [PlatformBdsLib/BdsPlatform.c] PlatformBdsRestoreNvVarsFromHardDisk() VisitAllInstancesOfProtocol for each simple file system: VisitingFileSystemInstance() ConnectNvVarsToFileSystem() [NvVarsFileLib/NvVarsFileLib.c] LoadNvVarsFromFs() [NvVarsFileLib/FsAccess.c] ReadNvVarsFile() +-------------> SerializeVariablesSetSerializedVariables() [SerializeVariablesLib/SerializeVariablesLib.c] | SerializeVariablesIterateInstanceVariables() | +-------------> IterateVariablesInBuffer() | | for each loaded / deserialized variable: | +-|-----------------> IterateVariablesCallbackSetSystemVariable() | | | gRT->SetVariable() | | | | | IterateVariablesInBuffer() stops processing variables as soon as the | | first error is encountered from the callback function. | | | | In this case the callback function is | IterateVariablesCallbackSetSystemVariable(), selected by SerializeVariablesSetSerializedVariables(). The result is that no NvVar is restored from the file after the first gRT->SetVariable() failure. On my system such a failure - never happens in an OVMF build with secure boot disabled, - happens *immediately* with SECURE_BOOT_ENABLE, because the first variable to restore is "AuthVarKeyDatabase". "AuthVarKeyDatabase" has the EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS attribute set. Since the loop tries to restore it before any keys (PK, KEK etc) are enrolled, gRT->SetVariable() rejects it with EFI_SECURITY_VIOLATION. Consequently the NvVar restore loop terminates immediately, and we never reach non-authenticated variables such as Boot#### and BootOrder. Until work on KVM-compatible flash emulation converges between qemu and OvmfPkg, improve the SECURE_BOOT_ENABLE boot experience by masking EFI_SECURITY_VIOLATION in the callback: - authenticated variables continue to be rejected same as before, but - at least we allow the loop to progress and restore non-authenticated variables, for example boot options. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14390 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: QemuBootOrder: recognize Ethernet OFW device pathsjljusten
Tested with the e1000, ne2k_pci, pcnet, rtl8139, and virtio iPXE UEFI oprom drivers distributed with qemu-1.5.0-rc1. Also tested with Intel's e1000 driver. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14367 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: adapt VirtioFlush()'s leading comment to the coding stylejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14362 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: adapt VirtioAppendDesc()'s leading comment to the coding stylejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14361 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: adapt VirtioPrepare()'s leading comment to the coding stylejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14360 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-14OvmfPkg: VirtioLib: populate the Available Ring correctlyjljusten
The descriptor table (also known as "queue") consists of descriptors. (The corresponding type in the code is VRING_DESC.) An individual descriptor describes a contiguous buffer, to be transferred uni-directionally between host and guest. Several descriptors in the descriptor table can be linked into a descriptor chain, specifying a bi-directional scatter-gather transfer between host and guest. Such a descriptor chain is also known as "virtio request". (The descriptor table can host sereval descriptor chains (in-flight virtio requests) in parallel, but the OVMF driver supports at most one chain, at any point in time.) The first descriptor in any descriptor chain is called "head descriptor". In order to submit a number of parallel requests (= a set of independent descriptor chains) from the guest to the host, the guest must put *only* the head descriptor of each separate chain onto the Available Ring. VirtioLib currently places the head of its one descriptor chain onto the Available Ring repeatedly, once for each single (head *or* dependent) descriptor in said descriptor chain. If the descriptor chain comprises N descriptors, this error amounts to submitting the same entire chain N times in parallel. Available Ring Descriptor table Ptr to head ----> Desc#0 (head of chain) Ptr to head --/ Desc#1 (next in same chain) ... / ... Ptr to head / Desc#(N-1) (last in same chain) Anatomy of a single virtio-blk READ request (a descriptor chain with three descriptors): virtio-blk request header, prepared by guest: VirtioAppendDesc PhysAddr=3FBC6050 Size=16 Flags=1 Head=1232 Next=1232 payload to be filled in by host: VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=1232 Next=1233 host status, to be filled in by host: VirtioAppendDesc PhysAddr=3FBC604F Size=1 Flags=2 Head=1232 Next=1234 Processing on the host side -- the descriptor chain is processed three times in parallel (its head is available to virtqueue_pop() thrice); the same chain is submitted/collected separately to/from AIO three times: virtio_queue_notify vdev VDEV vq VQ#0 virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0 virtqueue_pop vq VQ#0 elem EL#1 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#1 virtqueue_pop vq VQ#0 elem EL#2 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#2 virtio_blk_rw_complete req REQ#0 ret 0 virtio_blk_req_complete req REQ#0 status 0 virtio_blk_rw_complete req REQ#1 ret 0 virtio_blk_req_complete req REQ#1 status 0 virtio_blk_rw_complete req REQ#2 ret 0 virtio_blk_req_complete req REQ#2 status 0 On my Thinkpad T510 laptop with RHEL-6 as host, this probably leads to simultaneous DMA transfers targeting the same RAM area. Even though the source of each transfer is identical, the data is corrupted in the destination buffer -- the CRC32 calculated over the buffer varies, even though the origin of the transfers is the same, never rewritten LBA. SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=BF68A44D The problem is invisible on my HP Z400 workstation. Fix the request submission by: - building the only one descriptor chain supported by VirtioLib always at the beginning of the descriptor table, - ensuring the head descriptor of this chain is put on the Available Ring only once, - requesting the virtio spec's language to be cleaned up <http://lists.linuxfoundation.org/pipermail/virtualization/2013-April/024032.html>. Available Ring Descriptor table Ptr to head ----> Desc#0 (head of chain) Desc#1 (next in same chain) ... Desc#(N-1) (last in same chain) VirtioAppendDesc PhysAddr=3FBC6040 Size=16 Flags=1 Head=0 Next=0 VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=0 Next=1 VirtioAppendDesc PhysAddr=3FBC603F Size=1 Flags=2 Head=0 Next=2 virtio_queue_notify vdev VDEV vq VQ#0 virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0 virtio_blk_rw_complete req REQ#0 ret 0 virtio_blk_req_complete req REQ#0 status 0 SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=1EEB2B07 (The Crc32 was double-checked with edk2's and Linux's guest IDE driver.) 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14356 6f19259b-4bc3-4df7-8a09-765794883524
2013-03-04OvmfPkg: make sure ResetCold() and ResetWarm() never returnjljusten
Also, add a small delay after the 0xCF9 hard reset request -- on qemu/kvm the port access is translated to the qemu-internal system reset request by the CPU thread, and it might progress some more before the IO thread acts upon the system reset request. MicroSecondDelay() is implemented by OvmfPkg's own AcpiTimerLib. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14158 6f19259b-4bc3-4df7-8a09-765794883524
2013-03-04OvmfPkg: attempt to trigger cold reset through PIIX3 reset control registerjljusten
The reset requested via the keyboard controller (port 0x64) is actually a soft reset, but qemu has supported it since forever (plus qemu has not distinguished between hard reset and soft reset, although this is changing now). Therefore leave the current IoWrite() in place for compatibility. On qemu versions with commit 1ec4ba74 ("PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set"), use the PIIX3 RCR as first choice. In the future qemu will act differently on soft vs. hard reset requests, and we should honor that in ResetCold(). Writing to ioport 0xCF9 on qemu builds prior to commit 1ec4ba74 should have no effect. Access to the PCI host config register went through several implementations in qemu. Commit 9f6f0423 ("pci_host: rewrite using rwhandler") seems safe, both before and after. Commit d0ed8076 ("pci_host: convert conf index and data ports to memory API") inadvertently dropped the alignment/size check, causing a boot regression on NetBSD. It was fixed about six months later in commit cdde6ffc, which is current. Translating that to qemu releases, the bug was visible from v1.0 to v1.1.0. On physical hardware cycling between reset methods is sometimes necessary <http://mjg59.dreamwidth.org/3561.html>. On qemu the port access should trap immediately. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14157 6f19259b-4bc3-4df7-8a09-765794883524
2013-02-14OvmfPkg LoadLinuxLib: Use kernel's EFI entry point where availablejljusten
Usage of the EFI entry point was made feasible in the kernel x64 boot protocol 2.12 where a 32-bit & 64-bit entry point became well defined. http://git.kernel.org/linus/09c205af Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14132 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-29 08:13:25 +0000