From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 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 4CD00202E53B2 for ; Tue, 12 Feb 2019 21:44:24 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5B06842BC2; Wed, 13 Feb 2019 05:44:23 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-136.rdu2.redhat.com [10.10.120.136]) by smtp.corp.redhat.com (Postfix) with ESMTP id AB54C601B6; Wed, 13 Feb 2019 05:44:22 +0000 (UTC) To: Rebecca Cran References: <4656579.YNO7O01DYZ@photon.int.bluestop.org> <1568584.MsCH1bHPGx@photon.int.bluestop.org> <059fccc8-3ab5-057b-008a-efbeb30438a9@redhat.com> <2834820.0P3pStmDMi@photon.int.bluestop.org> From: Laszlo Ersek Cc: Rebecca Cran via edk2-devel Message-ID: Date: Wed, 13 Feb 2019 06:44:21 +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.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 13 Feb 2019 05:44:23 +0000 (UTC) Subject: Re: OVMF and TCP4, HTTP protocols X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 05:44:25 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 02/13/19 05:28, Rebecca Cran wrote: > On February 6, 2019 at 4:08:03 PM, Rebecca Cran via edk2-devel > (edk2-devel@lists.01.org ) wrote: >> >> Oh, that makes sense! Thanks, after disabling the existing code that was  >> opening SNP exclusively, things started working much better.  > > > I have a follow-up question. After opening the EFI_SIMPLE_NETWORK > protocol exclusively, should code be able to later call > gBS->CloseProtocol on the handle and subsequently start using TCP/HTTP?  > > From what I’ve seen, closing the protocol (I’m also calling > net->Shutdown(), and the CloseProtocol succeeds) has no effect and the > TCP and HTTP protocols still can’t be found/used. Sure, that's expected. Just because an agent releases a reference to a protocol interface, no other agent is expected to automatically bind the interface. In order to get back from SNP to the HTTP SB, you have to re-connect the related drivers (recursively). "Recursive" has dual meaning here. First, it means that, given a specific handle, and a protocol interface on that handle, another driver -- a device driver -- can consume the protocol interace, and install another protocol interface on the *same* handle. The other meaning of "recursive" is that a *bus* driver may produce a number of direct child handles (with appropriate device paths on them) for the original handle, and install the suitable protocol interface(s) on those child handles. In turn another driver will bind the protocol interfaces on the child handles. Thus "recursion" may occur on two axes -- one axis is the protocol stack on a given, single, handle; the other axis is the hierarchy of child handles (reflected by device paths). In the ConnectController() boot service, the first axis is covered automatically (it is not optional). The second axis is controlled by the "Recursive" parameter. In your case, I think it should suffice to call ConnectController() with Recursive=FALSE, on the controller that already has SNP. The HttpServiceBinding, Tcp6ServiceBinding and TCPv4ServiceBinding protocols seem to be installed on the same handle. (The device path on this handle ends with the MAC() node.) Once the HttpServiceBinding protocol instance exists, UEFI 2.7 "29.6.2.1 Usage Examples" provides a code example for a HTTP file download, including IPv4 address configuration with DHCP. Thanks, Laszlo