From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web09.8051.1579099931187807426 for ; Wed, 15 Jan 2020 06:52:11 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SOoT+QXl; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579099930; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jYlZ6GjXYspR38jd6ouMd1idIMMyclVdoulT+tz6Q2Q=; b=SOoT+QXl79W9Owq/2RaWYB0LEpC6iYPul5X75Eh1TaHhL81xM4CiDvvh0dVycLDxWFfXfO 62FHQvHUlpCLrz0dq5vbo72tvjButOjUGKN/j2w/MDmIRnSPM0ldbAiC2ndve8fKUWy5Gr n6Glws6YXeNTlCC1u8PwX0vEvumbD1Y= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-379-SyHY67XJPqywt6iyU4gbBw-1; Wed, 15 Jan 2020 09:52:05 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 45A93CEF40; Wed, 15 Jan 2020 14:52:04 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-98.ams2.redhat.com [10.36.116.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id 12E6010372F3; Wed, 15 Jan 2020 14:52:02 +0000 (UTC) Subject: Re: [RFC PATCH] ArmPkg/PlatformBmLib: defer GOP console discovery after Driver#### dispatch To: Ard Biesheuvel Cc: edk2-devel-groups-io , Leif Lindholm , "Ni, Ray" , Andrew Fish References: <20200115102217.3027-1-ard.biesheuvel@linaro.org> <23a9be06-791f-517a-ccd4-fd36c93af8b0@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 15 Jan 2020 15:52:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: SyHY67XJPqywt6iyU4gbBw-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 01/15/20 14:02, Ard Biesheuvel wrote: > On Wed, 15 Jan 2020 at 13:50, Laszlo Ersek wrote: >> (3) So how about the following approach: >> >> (3a) factor the following sequence: >> >> FilterAndProcess (&gEfiPciIoProtocolGuid, IsPciDisplay, Connect); >> FilterAndProcess (&gEfiGraphicsOutputProtocolGuid, NULL, AddOutput); >> >> out to a helper function, >> >> (3b) call the extracted sequence in *both* its current place, *and* at >> the top of PlatformBootManagerAfterConsole() (instead of >> EfiBootManagerConnectVideoController())? >> >> ? >> >> I expect this should give you *some* consoles in BeforeConsole() (on >> such PCI and non-PCI graphics controllers whose drivers are in the >> platform firmware), just to be safe; and *all* the rest would be picked >> up in AfterConsole(). >> > > I wonder whether there is a point to doing it twice, regardless of > whether we are talking about PCI or non-PCI. I experimented with just > moving those calls to AfterConsole(), and I get basically the same > behavior as with this patch. Looking at BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c], admittedly quite little happens between the calls to PlatformBootManagerBeforeConsole() and PlatformBootManagerAfterConsole(). What if a UEFI driver, loaded from a Driver#### option, prints a message to the UEFI console, in its entry point function? Do we want such messages to appear on platform framebuffers? ... Hmmm, I felt that the Driver Writer's Guide spoke some words on this, and indeed. In 3.15.3 "Connecting consoles", the Note at the end includes the following sentence: UEFI Drivers should never directly access console devices except for the few UEFI driver related services that explicitly allow user interaction. In most cases, UEFI drivers use HII infrastructure to present information to users. I don't know what those "few UEFI driver related services" are supposed to be "that explicitly allow user interaction". So with the (somewhat incomplete) information I seem to have, I must agree that simply moving those two function calls should be safe enough. Thanks Laszlo