2012-08-28 01:28:30 +02:00
|
|
|
/** @file
|
|
|
|
|
Rewrite the BootOrder NvVar based on QEMU's "bootorder" fw_cfg file --
|
|
|
|
|
include file.
|
|
|
|
|
|
2015-01-02 13:07:57 +01:00
|
|
|
Copyright (C) 2012-2014, Red Hat, Inc.
|
2012-08-28 01:28:30 +02:00
|
|
|
|
2019-04-04 01:06:33 +02:00
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
2012-08-28 01:28:30 +02:00
|
|
|
**/
|
|
|
|
|
|
2015-01-02 13:07:57 +01:00
|
|
|
#ifndef __QEMU_BOOT_ORDER_LIB_H__
|
|
|
|
|
#define __QEMU_BOOT_ORDER_LIB_H__
|
2012-08-28 01:28:30 +02:00
|
|
|
|
|
|
|
|
#include <Uefi/UefiBaseType.h>
|
|
|
|
|
#include <Base.h>
|
|
|
|
|
|
OvmfPkg/QemuBootOrderLib: add ConnectDevicesFromQemu()
QemuBootOrderLib expects PlatformBootManagerLib to call the following
triplet:
(1) EfiBootManagerConnectAll(),
(2) EfiBootManagerRefreshAllBootOption(),
(3) SetBootOrderFromQemu().
This leads to bad performance, when many devices exist such that the
firmware can drive them, but they aren't marked for booting in the
"bootorder" fw_cfg file. Namely,
(1) EfiBootManagerConnectAll() talks to all hardware, which takes long.
Plus some DriverBindingStart() functions write NV variables, which is
also slow. (For example, the IP config policy for each NIC is stored
in an NV var that is named after the MAC).
(2) EfiBootManagerRefreshAllBootOption() generates boot options from the
protocol instances produced by (1). Writing boot options is slow.
(3) Under the above circumstances, SetBootOrderFromQemu() removes most of
the boot options produced by (2). Erasing boot options is slow.
Introduce ConnectDevicesFromQemu() as a replacement for (1): only connect
devices that the QEMU user actually wants to boot off of.
(There's a slight loss of compatibility when a platform switches from
EfiBootManagerConnectAll() to ConnectDevicesFromQemu().
EfiBootManagerConnectAll() may produce UEFI device paths that are unknown
to QemuBootOrderLib (that is, for neither PCI- nor virtio-mmio-based
devices). The BootOrderComplete() function lets such unmatched boot
options survive at the end of the boot order. With
ConnectDevicesFromQemu(), these options will not be auto-generated in the
first place. They may still be produced by other means.
SetBootOrderFromQemu() is not modified in any way; reordering+filtering
boot options remains a separate task.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
2018-03-13 18:37:17 +01:00
|
|
|
/**
|
|
|
|
|
Connect devices based on the boot order retrieved from QEMU.
|
|
|
|
|
|
|
|
|
|
Attempt to retrieve the "bootorder" fw_cfg file from QEMU. Translate the
|
|
|
|
|
OpenFirmware device paths therein to UEFI device path fragments. Connect the
|
|
|
|
|
devices identified by the UEFI devpath prefixes as narrowly as possible, then
|
|
|
|
|
connect all their child devices, recursively.
|
|
|
|
|
|
|
|
|
|
If this function fails, then platform BDS should fall back to
|
|
|
|
|
EfiBootManagerConnectAll(), or some other method for connecting any expected
|
|
|
|
|
boot devices.
|
|
|
|
|
|
|
|
|
|
@retval RETURN_SUCCESS The "bootorder" fw_cfg file has been
|
|
|
|
|
parsed, and the referenced device-subtrees
|
|
|
|
|
have been connected.
|
|
|
|
|
|
|
|
|
|
@retval RETURN_UNSUPPORTED QEMU's fw_cfg is not supported.
|
|
|
|
|
|
|
|
|
|
@retval RETURN_NOT_FOUND Empty or nonexistent "bootorder" fw_cfg
|
|
|
|
|
file.
|
|
|
|
|
|
|
|
|
|
@retval RETURN_INVALID_PARAMETER Parse error in the "bootorder" fw_cfg file.
|
|
|
|
|
|
|
|
|
|
@retval RETURN_OUT_OF_RESOURCES Memory allocation failed.
|
|
|
|
|
|
|
|
|
|
@return Error statuses propagated from underlying
|
|
|
|
|
functions.
|
|
|
|
|
**/
|
|
|
|
|
RETURN_STATUS
|
|
|
|
|
EFIAPI
|
|
|
|
|
ConnectDevicesFromQemu (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2022-07-19 17:12:48 +02:00
|
|
|
/**
|
|
|
|
|
Write qemu boot order to uefi variables.
|
|
|
|
|
|
|
|
|
|
Attempt to retrieve the "bootorder" fw_cfg file from QEMU. Translate
|
|
|
|
|
the OpenFirmware device paths therein to UEFI device path fragments.
|
|
|
|
|
|
|
|
|
|
On Success store the device path in QemuBootOrderNNNN variables.
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
EFIAPI
|
|
|
|
|
StoreQemuBootOrder (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2012-08-28 01:28:30 +02:00
|
|
|
/**
|
|
|
|
|
|
|
|
|
|
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
|
2016-05-17 19:22:17 +02:00
|
|
|
translated fragments against the current list of boot options, and rewrite
|
|
|
|
|
the BootOrder NvVar so that it corresponds to the order described in fw_cfg.
|
2012-08-28 01:28:30 +02:00
|
|
|
|
OvmfPkg/QemuBootOrderLib: add ConnectDevicesFromQemu()
QemuBootOrderLib expects PlatformBootManagerLib to call the following
triplet:
(1) EfiBootManagerConnectAll(),
(2) EfiBootManagerRefreshAllBootOption(),
(3) SetBootOrderFromQemu().
This leads to bad performance, when many devices exist such that the
firmware can drive them, but they aren't marked for booting in the
"bootorder" fw_cfg file. Namely,
(1) EfiBootManagerConnectAll() talks to all hardware, which takes long.
Plus some DriverBindingStart() functions write NV variables, which is
also slow. (For example, the IP config policy for each NIC is stored
in an NV var that is named after the MAC).
(2) EfiBootManagerRefreshAllBootOption() generates boot options from the
protocol instances produced by (1). Writing boot options is slow.
(3) Under the above circumstances, SetBootOrderFromQemu() removes most of
the boot options produced by (2). Erasing boot options is slow.
Introduce ConnectDevicesFromQemu() as a replacement for (1): only connect
devices that the QEMU user actually wants to boot off of.
(There's a slight loss of compatibility when a platform switches from
EfiBootManagerConnectAll() to ConnectDevicesFromQemu().
EfiBootManagerConnectAll() may produce UEFI device paths that are unknown
to QemuBootOrderLib (that is, for neither PCI- nor virtio-mmio-based
devices). The BootOrderComplete() function lets such unmatched boot
options survive at the end of the boot order. With
ConnectDevicesFromQemu(), these options will not be auto-generated in the
first place. They may still be produced by other means.
SetBootOrderFromQemu() is not modified in any way; reordering+filtering
boot options remains a separate task.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
2018-03-13 18:37:17 +01:00
|
|
|
Platform BDS should call this function after connecting any expected boot
|
|
|
|
|
devices and calling EfiBootManagerRefreshAllBootOption ().
|
2012-08-28 01:28:30 +02:00
|
|
|
|
|
|
|
|
@retval RETURN_SUCCESS BootOrder NvVar rewritten.
|
|
|
|
|
|
|
|
|
|
@retval RETURN_UNSUPPORTED QEMU's fw_cfg is not supported.
|
|
|
|
|
|
|
|
|
|
@retval RETURN_NOT_FOUND Empty or nonexistent "bootorder" fw_cfg
|
|
|
|
|
file, or no match found between the
|
|
|
|
|
"bootorder" fw_cfg file and BootOptionList.
|
|
|
|
|
|
|
|
|
|
@retval RETURN_INVALID_PARAMETER Parse error in the "bootorder" fw_cfg file.
|
|
|
|
|
|
|
|
|
|
@retval RETURN_OUT_OF_RESOURCES Memory allocation failed.
|
|
|
|
|
|
|
|
|
|
@return Values returned by gBS->LocateProtocol ()
|
|
|
|
|
or gRT->SetVariable ().
|
|
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
RETURN_STATUS
|
2018-03-13 16:41:14 +01:00
|
|
|
EFIAPI
|
2012-08-28 01:28:30 +02:00
|
|
|
SetBootOrderFromQemu (
|
2016-05-17 19:22:17 +02:00
|
|
|
VOID
|
2012-08-28 01:28:30 +02:00
|
|
|
);
|
2015-01-02 13:07:57 +01:00
|
|
|
|
OvmfPkg: QemuBootOrderLib: expose QEMU's "-boot menu=on[,splash-time=N]"
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
2015-01-14 17:25:54 +01:00
|
|
|
/**
|
|
|
|
|
Calculate the number of seconds we should be showing the FrontPage progress
|
|
|
|
|
bar for.
|
|
|
|
|
|
|
|
|
|
@return The TimeoutDefault argument for PlatformBdsEnterFrontPage().
|
|
|
|
|
**/
|
|
|
|
|
UINT16
|
2018-03-13 16:41:14 +01:00
|
|
|
EFIAPI
|
OvmfPkg: QemuBootOrderLib: expose QEMU's "-boot menu=on[,splash-time=N]"
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
2015-01-14 17:25:54 +01:00
|
|
|
GetFrontPageTimeoutFromQemu (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2015-01-02 13:07:57 +01:00
|
|
|
#endif
|
