Implement new API DebugPrintLevelEnabled() to base on PCD PcdFixedDebugPrintErrorLevel.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16797 6f19259b-4bc3-4df7-8a09-765794883524
The QEMU command line option
-boot menu=on
is meant to have the guest firmware wait for a firmware-specific interval
for the user to enter the boot menu. During the wait, the user can opt to
enter the boot menu, or interrupt the wait and proceed to booting at once.
If the wait interval elapses, the firmware should boot as it normally
would.
The QEMU command line option
-boot menu=on,splash-time=N
means the same, except the firmware should wait for cca. N milliseconds
instead of a firmware-specific interval.
We can approximate this behavior quite well for edk2's virtual platforms
because the Intel BDS front page already supports a progress bar, with
semantics similar to the above. Let's distill the fw_cfg bits underlying
"-boot menu=on,splash-time=N" for the BDS policies, in the form of a
timeout value they can pass to Intel's PlatformBdsEnterFrontPage().
If the boot menu is not requested, we return
"gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut", which
is what the virtual platforms use right now.
If the boot menu is requested without specifying the timeout, we return
the same PCD, unless it would cause us to skip the boot menu at once. In
the latter case, we return 3 seconds (as an approximation of the 2500 ms
SeaBIOS default.)
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170507
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16610 6f19259b-4bc3-4df7-8a09-765794883524
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Liming Gao
Laszlo Ersek
Gabriel Somlo
Jordan Justen
Ruiyu Ni
Paolo Bonzini
Mauro Faccenda
Olivier Martin
Matt Fleming