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 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
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
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
We're supposed to zero everything in the kernel bootparams that we don't
explicitly initialise, other than the setup_header from 0x1f1 onwards
for a precisely defined length, which is copied from the bzImage.
We're *not* supposed to just pass the garbage that we happened to find
in the bzImage file surrounding the setup_header.
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@14052 6f19259b-4bc3-4df7-8a09-765794883524
If QEMU's -kernel parameter was used, then download the
kernel from the FwCfg interface, and launch it. (See -kernel,
-initrd, -append) The application uses the LoadLinuxLib to boot
the kernel image.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13923 6f19259b-4bc3-4df7-8a09-765794883524
2 nodes in an OpenFirmware device path are sufficient for the generic
check at the beginning of TranslateOfwNodes(). The driver specific
branches check for the necessary nodes individually.
The number of nodes saved for examination is unchanged.
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@13800 6f19259b-4bc3-4df7-8a09-765794883524
Set the boot order based on configuration retrieved from QEMU.
Attempt to retrieve the "bootorder" fw_cfg file from QEMU. Translate the
OpenFirmware device paths therein to UEFI device path fragments. Match the
translated fragments against the enumerated BootOptionList, and rewrite
the BootOrder NvVar so that it corresponds to the order described in
fw_cfg.
The user is expected to configure working boot options first.
Tested via virt-manager's boot order widget.
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@13683 6f19259b-4bc3-4df7-8a09-765794883524
Older QEMU versions would load vgabios-cirrus.bin at 0xc0000 in
system RAM. We would then find this ROM, and try to run it, since
it would be our QEMU Video driver.
Now, the QEMU Video driver is just merged into the main OVMF
firmware image, so this support is unused.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13522 6f19259b-4bc3-4df7-8a09-765794883524
If the bit is not set, then the only method ACPI defines
for setting it is to use the SMI SCI enable code path.
Since OVMF does not support SMM, we must enable the
bit during boot.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Bei Guan <gbtju85@gmail.com>
Reviewed-by: Bei Guan <gbtju85@gmail.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13278 6f19259b-4bc3-4df7-8a09-765794883524
This call can cause a reset, and is most critical for ACPI S3/S4
resume situations. OVMF does not support S3/S4.
OVMF does not have true non-volatile variable support, so
this call could cause a continuous reset situation in certain
scenarios. (The BdsLibSaveMemoryTypeInformation may set an
non-volatile variable, and then reset with the assumption that
the variable will still exist during the next boot.)
Additionally, some version of QEMU appear to hang when the
port 64 reset is initiated.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10927 6f19259b-4bc3-4df7-8a09-765794883524
Note:
* This only works before ExitBootServices
* For OVMF, variables are only preserved on the disk if there
is a hard disk connected which has a writeable FAT file system.
The Ovmf/Library/EmuVariableFvbLib library will look for the
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent PCD to be set to
a non-zero value. If set, it is treated as an event handle, and
each write to the EmuVariableFvb will cause the event to be
signaled.
In this change, the OVMF platform BDS library sets up this event,
and sets the PCD so that after each write to the EMU Variable FVB,
the non-volatile variables will be saved out to the file system.
The end result is that NV variables that are written prior to the
ExitBootServices call should be preserved by storing them on the
disk.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9318 6f19259b-4bc3-4df7-8a09-765794883524
QEMU will automatically fill the video BIOS image into memory at the
legacy video BIOS memory location (0xc0000). This code will look
there for a EFI option rom image, and load it if it found. This
allows the video option ROM to be separated out from the main system
firmware image.
QEMU does not appear to emulate the PCI rom expansion method
for making the video BIOS available to the system.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8942 6f19259b-4bc3-4df7-8a09-765794883524
It is not proper for a library implementation to assume the names of function in a parent module.
Instead, they must be designed as the pointers to these two BdsDxe functions and passed in.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8931 6f19259b-4bc3-4df7-8a09-765794883524
Paolo Bonzini
Laszlo Ersek
Mauro Faccenda
Ruiyu Ni
jljusten
mdkinney
rsun3
hhtian
lgao4
klu2
qhuang8
eric_tian