From: Laszlo Ersek <lersek@redhat.com>
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Jordan Justen <jordan.l.justen@intel.com>,
Shannon Zhao <zhaoshenglong@huawei.com>,
Xiang Zheng <xiang.zheng@linaro.org>
Subject: [PATCH 4/6] OvmfPkg/QemuBootOrderLib: add ConnectDevicesFromQemu()
Date: Tue, 13 Mar 2018 22:22:31 +0100 [thread overview]
Message-ID: <20180313212233.19215-5-lersek@redhat.com> (raw)
In-Reply-To: <20180313212233.19215-1-lersek@redhat.com>
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>
---
OvmfPkg/Include/Library/QemuBootOrderLib.h | 39 ++++-
OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c | 154 +++++++++++++++++++-
2 files changed, 189 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/Include/Library/QemuBootOrderLib.h b/OvmfPkg/Include/Library/QemuBootOrderLib.h
index 874344a95d80..d17de3bb8fae 100644
--- a/OvmfPkg/Include/Library/QemuBootOrderLib.h
+++ b/OvmfPkg/Include/Library/QemuBootOrderLib.h
@@ -20,6 +20,41 @@
#include <Base.h>
+/**
+ 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
+ );
+
+
/**
Set the boot order based on configuration retrieved from QEMU.
@@ -29,8 +64,8 @@
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.
- Platform BDS should call this function after EfiBootManagerConnectAll () and
- EfiBootManagerRefreshAllBootOption () return.
+ Platform BDS should call this function after connecting any expected boot
+ devices and calling EfiBootManagerRefreshAllBootOption ().
@retval RETURN_SUCCESS BootOrder NvVar rewritten.
diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
index a4213cf6d267..15e4c67e48c5 100644
--- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
+++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
@@ -1453,6 +1453,156 @@ TranslateOfwPath (
}
+/**
+ 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
+ )
+{
+ RETURN_STATUS Status;
+ FIRMWARE_CONFIG_ITEM FwCfgItem;
+ UINTN FwCfgSize;
+ CHAR8 *FwCfg;
+ EFI_STATUS EfiStatus;
+ EXTRA_ROOT_BUS_MAP *ExtraPciRoots;
+ CONST CHAR8 *FwCfgPtr;
+ UINTN NumConnected;
+ UINTN TranslatedSize;
+ CHAR16 Translated[TRANSLATION_OUTPUT_SIZE];
+
+ Status = QemuFwCfgFindFile ("bootorder", &FwCfgItem, &FwCfgSize);
+ if (RETURN_ERROR (Status)) {
+ return Status;
+ }
+
+ if (FwCfgSize == 0) {
+ return RETURN_NOT_FOUND;
+ }
+
+ FwCfg = AllocatePool (FwCfgSize);
+ if (FwCfg == NULL) {
+ return RETURN_OUT_OF_RESOURCES;
+ }
+
+ QemuFwCfgSelectItem (FwCfgItem);
+ QemuFwCfgReadBytes (FwCfgSize, FwCfg);
+ if (FwCfg[FwCfgSize - 1] != '\0') {
+ Status = RETURN_INVALID_PARAMETER;
+ goto FreeFwCfg;
+ }
+ DEBUG ((DEBUG_VERBOSE, "%a: FwCfg:\n", __FUNCTION__));
+ DEBUG ((DEBUG_VERBOSE, "%a\n", FwCfg));
+ DEBUG ((DEBUG_VERBOSE, "%a: FwCfg: <end>\n", __FUNCTION__));
+
+ if (FeaturePcdGet (PcdQemuBootOrderPciTranslation)) {
+ EfiStatus = CreateExtraRootBusMap (&ExtraPciRoots);
+ if (EFI_ERROR (EfiStatus)) {
+ Status = (RETURN_STATUS)EfiStatus;
+ goto FreeFwCfg;
+ }
+ } else {
+ ExtraPciRoots = NULL;
+ }
+
+ //
+ // Translate each OpenFirmware path to a UEFI devpath prefix.
+ //
+ FwCfgPtr = FwCfg;
+ NumConnected = 0;
+ TranslatedSize = ARRAY_SIZE (Translated);
+ Status = TranslateOfwPath (&FwCfgPtr, ExtraPciRoots, Translated,
+ &TranslatedSize);
+ while (!RETURN_ERROR (Status)) {
+ EFI_DEVICE_PATH_PROTOCOL *DevicePath;
+ EFI_HANDLE Controller;
+
+ //
+ // Convert the UEFI devpath prefix to binary representation.
+ //
+ ASSERT (Translated[TranslatedSize] == L'\0');
+ DevicePath = ConvertTextToDevicePath (Translated);
+ if (DevicePath == NULL) {
+ Status = RETURN_OUT_OF_RESOURCES;
+ goto FreeExtraPciRoots;
+ }
+ //
+ // Advance along DevicePath, connecting the nodes individually, and asking
+ // drivers not to produce sibling nodes. Retrieve the controller handle
+ // associated with the full DevicePath -- this is the device that QEMU's
+ // OFW devpath refers to.
+ //
+ EfiStatus = EfiBootManagerConnectDevicePath (DevicePath, &Controller);
+ FreePool (DevicePath);
+ if (EFI_ERROR (EfiStatus)) {
+ Status = (RETURN_STATUS)EfiStatus;
+ goto FreeExtraPciRoots;
+ }
+ //
+ // Because QEMU's OFW devpaths have lesser expressive power than UEFI
+ // devpaths (i.e., DevicePath is considered a prefix), connect the tree
+ // rooted at Controller, recursively. If no children are produced
+ // (EFI_NOT_FOUND), that's OK.
+ //
+ EfiStatus = gBS->ConnectController (Controller, NULL, NULL, TRUE);
+ if (EFI_ERROR (EfiStatus) && EfiStatus != EFI_NOT_FOUND) {
+ Status = (RETURN_STATUS)EfiStatus;
+ goto FreeExtraPciRoots;
+ }
+ ++NumConnected;
+ //
+ // Move to the next OFW devpath.
+ //
+ TranslatedSize = ARRAY_SIZE (Translated);
+ Status = TranslateOfwPath (&FwCfgPtr, ExtraPciRoots, Translated,
+ &TranslatedSize);
+ }
+
+ if (Status == RETURN_NOT_FOUND && NumConnected > 0) {
+ DEBUG ((DEBUG_INFO, "%a: %Lu OpenFirmware device path(s) connected\n",
+ __FUNCTION__, (UINT64)NumConnected));
+ Status = RETURN_SUCCESS;
+ }
+
+FreeExtraPciRoots:
+ if (ExtraPciRoots != NULL) {
+ DestroyExtraRootBusMap (ExtraPciRoots);
+ }
+
+FreeFwCfg:
+ FreePool (FwCfg);
+
+ return Status;
+}
+
+
/**
Convert the UEFI DevicePath to full text representation with DevPathToText,
@@ -1743,8 +1893,8 @@ PruneBootVariables (
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.
- Platform BDS should call this function after EfiBootManagerConnectAll () and
- EfiBootManagerRefreshAllBootOption () return.
+ Platform BDS should call this function after connecting any expected boot
+ devices and calling EfiBootManagerRefreshAllBootOption ().
@retval RETURN_SUCCESS BootOrder NvVar rewritten.
--
2.14.1.3.gb7cf6e02401b
next prev parent reply other threads:[~2018-03-13 21:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-13 21:22 [PATCH 0/6] OvmfPkg, ArmVirtQemu: leaner platform BDS policy for connecting devices Laszlo Ersek
2018-03-13 21:22 ` [PATCH 1/6] OvmfPkg/QemuBootOrderLib: wrap overlong line Laszlo Ersek
2018-03-13 21:22 ` [PATCH 2/6] OvmfPkg/QemuBootOrderLib: add missing EFIAPI specifiers Laszlo Ersek
2018-03-13 21:22 ` [PATCH 3/6] OvmfPkg/QemuBootOrderLib: clean up translation of virtio-net over MMIO Laszlo Ersek
2018-03-13 21:22 ` Laszlo Ersek [this message]
2018-03-13 21:22 ` [PATCH 5/6] OvmfPkg/PlatformBootManagerLib: minimize the set of connected devices Laszlo Ersek
2018-03-13 21:22 ` [PATCH 6/6] ArmVirtPkg/PlatformBootManagerLib: " Laszlo Ersek
2018-03-14 9:01 ` [PATCH 0/6] OvmfPkg, ArmVirtQemu: leaner platform BDS policy for connecting devices Ard Biesheuvel
2018-03-14 9:16 ` zhengxiang (A)
2018-03-14 10:30 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180313212233.19215-5-lersek@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox