From nobody Tue Apr 30 03:57:11 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1511809454194632.6112262120894; Mon, 27 Nov 2017 11:04:14 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id F1DA721B00DC1; Mon, 27 Nov 2017 10:59:50 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9F93A20359E90 for ; Mon, 27 Nov 2017 10:59:49 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8789585545; Mon, 27 Nov 2017 19:04:11 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-232.rdu2.redhat.com [10.10.120.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6D6AD5D753; Mon, 27 Nov 2017 19:04:10 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org From: Laszlo Ersek To: edk2-devel-01 Date: Mon, 27 Nov 2017 20:03:53 +0100 Message-Id: <20171127190354.13699-2-lersek@redhat.com> In-Reply-To: <20171127190354.13699-1-lersek@redhat.com> References: <20171127190354.13699-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 27 Nov 2017 19:04:11 +0000 (UTC) Subject: [edk2] [PATCH 1/2] OvmfPkg/QemuBootOrderLib: skip already matched / appended UEFI boot opts X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jordan Justen , Ard Biesheuvel MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" The SetBootOrderFromQemu() function implements a nested loop where - the outer loop iterates over all OpenFirmware (OFW) device paths in the QEMU boot order, and translates each to a UEFI device path prefix; - the inner loop matches the current (translated) prefix against all active UEFI boot options in turn; - if the UEFI boot option is matched by the translated prefix, the UEFI boot option is appended to the "new" UEFI boot order, and marked as "has been appended". This patch adds a micro-optimization where already matched / appended UEFI boot options are skipped in the inner loop. This is not a functional change. A functional change would be if, as a consequence of the patch, some UEFI boot options would no longer be *doubly* matched. For a UEFI boot option to be matched by two translated prefixes, one of those prefixes would have to be a (proper, or equal) prefix of the other prefix. The PCI and MMIO OFW translation routines output such only in the following cases: - When the original OFW device paths are prefixes of each other. This is not possible from the QEMU side. (Only leaf devices are bootable.) - When the translation rules in the routines are incomplete, and don't look at the OFW device paths for sufficient length (i.e., at nodes where they would already differ, and the difference would show up in the translation output). This would be a shortcoming of the translation routines and should be fixed in TranslatePciOfwNodes() and TranslateMmioOfwNodes(), whenever identified. Even in the second case, this patch would replace the double appending of a single UEFI boot option (matched by two different OFW device paths) with a correct, or cross-, matching of two different UEFI boot options. Again, this is not expected, but arguably it would be more correct than duplicate boot option appending, should it occur due to any (unexpected, unknown) lack of detail in the translation routines. Cc: Ard Biesheuvel Cc: Jordan Justen Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek Acked-by: Ard Biesheuvel --- OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c b/OvmfPkg/= Library/QemuBootOrderLib/QemuBootOrderLib.c index 7c1f375beb20..a9a62e9d4007 100644 --- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c +++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c @@ -1849,31 +1849,32 @@ SetBootOrderFromQemu ( // TranslatedSize =3D ARRAY_SIZE (Translated); Status =3D TranslateOfwPath (&FwCfgPtr, ExtraPciRoots, Translated, &TranslatedSize); while (Status =3D=3D RETURN_SUCCESS || Status =3D=3D RETURN_UNSUPPORTED || Status =3D=3D RETURN_PROTOCOL_ERROR || Status =3D=3D RETURN_BUFFER_TOO_SMALL) { if (Status =3D=3D RETURN_SUCCESS) { UINTN Idx; =20 // // match translated OpenFirmware path against all active boot options // for (Idx =3D 0; Idx < ActiveCount; ++Idx) { - if (Match ( + if (!ActiveOption[Idx].Appended && + Match ( Translated, TranslatedSize, // contains length, not size, in CHAR16's he= re ActiveOption[Idx].BootOption->FilePath ) ) { // // match found, store ID and continue with next OpenFirmware path // Status =3D BootOrderAppend (&BootOrder, &ActiveOption[Idx]); if (Status !=3D RETURN_SUCCESS) { goto ErrorFreeExtraPciRoots; } break; } } // scanned all active boot options --=20 2.14.1.3.gb7cf6e02401b _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel From nobody Tue Apr 30 03:57:11 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1511809457497352.1226510788197; Mon, 27 Nov 2017 11:04:17 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 362C021B00DFC; Mon, 27 Nov 2017 10:59:54 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 86DCE21B00DEC for ; Mon, 27 Nov 2017 10:59:52 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6B64D85545; Mon, 27 Nov 2017 19:04:14 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-232.rdu2.redhat.com [10.10.120.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id E14915EDE8; Mon, 27 Nov 2017 19:04:12 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org From: Laszlo Ersek To: edk2-devel-01 Date: Mon, 27 Nov 2017 20:03:54 +0100 Message-Id: <20171127190354.13699-3-lersek@redhat.com> In-Reply-To: <20171127190354.13699-1-lersek@redhat.com> References: <20171127190354.13699-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 27 Nov 2017 19:04:14 +0000 (UTC) Subject: [edk2] [PATCH 2/2] OvmfPkg/QemuBootOrderLib: let an OFW devpath match multiple UEFI boot opts X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jordan Justen , Ard Biesheuvel MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" This means that SetBootOrderFromQemu() will preserve all UEFI boot options matched by any given OFW devpath, such as PXEv4, HTTPv4, PXEv6 and HTTPv6 boot options for the same NIC. Currently we stop the matching / appending for the OFW devpath coming from the outer loop whenever we find the first UEFI boot option match in the inner loop. (The previous patch was about multiple OFW devpaths matching a single UEFI boot option (which should never happen). This patch is about a single OFW devpath matching multiple UEFI boot options. With the "break" statement removed here, the small optimization from the last patch becomes a bit more relevant, because now the inner loop always counts up to ActiveCount.) Cc: Ard Biesheuvel Cc: Jordan Justen Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek Acked-by: Ard Biesheuvel --- OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c | 1 - 1 file changed, 1 deletion(-) diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c b/OvmfPkg/= Library/QemuBootOrderLib/QemuBootOrderLib.c index a9a62e9d4007..366104adf535 100644 --- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c +++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c @@ -1863,31 +1863,30 @@ SetBootOrderFromQemu ( for (Idx =3D 0; Idx < ActiveCount; ++Idx) { if (!ActiveOption[Idx].Appended && Match ( Translated, TranslatedSize, // contains length, not size, in CHAR16's he= re ActiveOption[Idx].BootOption->FilePath ) ) { // // match found, store ID and continue with next OpenFirmware path // Status =3D BootOrderAppend (&BootOrder, &ActiveOption[Idx]); if (Status !=3D RETURN_SUCCESS) { goto ErrorFreeExtraPciRoots; } - break; } } // scanned all active boot options } // translation successful =20 TranslatedSize =3D ARRAY_SIZE (Translated); Status =3D TranslateOfwPath (&FwCfgPtr, ExtraPciRoots, Translated, &TranslatedSize); } // scanning of OpenFirmware paths done =20 if (Status =3D=3D RETURN_NOT_FOUND && BootOrder.Produced > 0) { // // No more OpenFirmware paths, some matches found: rewrite BootOrder N= vVar. // Some of the active boot options that have not been selected over fw= _cfg // should be preserved at the end of the boot order. // --=20 2.14.1.3.gb7cf6e02401b _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel