OVMF and TCP4, HTTP protocols

OVMF and TCP4, HTTP protocols

[Rebecca Cran]

I'm trying to fetch a file over HTTP in a boot loader, but gBS-
>LocateHandleBuffer doesn't find either of the EFI_TCP4_SERVICE_BINDING_PROTCOL 
or EFI_HTTP_SERVICE_BINDING_PROTOCOL.

I'm running a build of OVMF from git master from a few weeks ago.
Should they exist and be usable, or does OVMF only support the 
EFI_SIMPLE_NETWORK_PROTOCOL?

-- 
Rebecca Cran

Re: OVMF and TCP4, HTTP protocols

[Laszlo Ersek]

Hello Rebecca,

On 02/06/19 07:06, Rebecca Cran via edk2-devel wrote:
> I'm trying to fetch a file over HTTP in a boot loader, but gBS-
>> LocateHandleBuffer doesn't find either of the EFI_TCP4_SERVICE_BINDING_PROTCOL 
> or EFI_HTTP_SERVICE_BINDING_PROTOCOL.
> 
> I'm running a build of OVMF from git master from a few weeks ago.
> Should they exist and be usable, or does OVMF only support the 
> EFI_SIMPLE_NETWORK_PROTOCOL?
> 

please refer to the HTTP_BOOT_ENABLE define in the OVMF DSC files; the
default value is FALSE.

If you'd like HTTP over IPv6, then please pass -D NETWORK_IP6_ENABLE on
the "build" cmdline as well.

Thanks,
Laszlo

Re: OVMF and TCP4, HTTP protocols

[Rebecca Cran]

On Wednesday, 6 February 2019 09:36:43 MST Laszlo Ersek wrote:

> please refer to the HTTP_BOOT_ENABLE define in the OVMF DSC files; the
> default value is FALSE.
> 
> If you'd like HTTP over IPv6, then please pass -D NETWORK_IP6_ENABLE on
> the "build" cmdline as well.

Thanks. I'm already building with HTTP_BOOT_ENABLE though, and successfully 
fetching loader.efi from the web server. However once loader.efi runs, my code 
can't find the HTTP or TCPv4 protocols.

>>Start HTTP Boot over IPv4.....
  Station IP address is 192.168.0.119

  URI: http://192.168.0.1/boot/loader.efi
  File Size: 480256 Bytes
  Downloading...100%

-- 
Rebecca Cran

Re: OVMF and TCP4, HTTP protocols

[Laszlo Ersek]

On 02/06/19 18:44, Rebecca Cran wrote:
> On Wednesday, 6 February 2019 09:36:43 MST Laszlo Ersek wrote:
> 
>> please refer to the HTTP_BOOT_ENABLE define in the OVMF DSC files; the
>> default value is FALSE.
>>
>> If you'd like HTTP over IPv6, then please pass -D NETWORK_IP6_ENABLE on
>> the "build" cmdline as well.
> 
> Thanks. I'm already building with HTTP_BOOT_ENABLE though, and successfully 
> fetching loader.efi from the web server. However once loader.efi runs, my code 
> can't find the HTTP or TCPv4 protocols.
> 
>>> Start HTTP Boot over IPv4.....
>   Station IP address is 192.168.0.119
> 
>   URI: http://192.168.0.1/boot/loader.efi
>   File Size: 480256 Bytes
>   Downloading...100%
> 

Is "loader.efi" opaque, or do we know what it does?

For example, if it opens SNP with BY_DRIVER|EXCLUSIVE attributes, then
everything on top will be disconnected.

(I don't understand clearly if "loader.efi" is your own code in fact.)

Here's an idea:

(1) Build "loader.efi" and code "around" it with

  OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf

as the DebugLib instance. Then debug messages from the application and
the platform firmware will be nicely intermixed on the QEMU debug port.

(2) Add a DEBUG_INFO message to CoreUninstallProtocolInterface()
[MdeModulePkg/Core/Dxe/Hand/Handle.c], logging the fact and the protocol
GUID.

(3) Search the log for installation & uninstallation of the GUID

  BDC8E6AF-D9BC-4379-A72A-E0C4E75DAE1C

(EFI_HTTP_SERVICE_BINDING_PROTOCOL). Perhaps you can correlate those log
entries with other events.

Thanks
Laszlo

Re: OVMF and TCP4, HTTP protocols

[Rebecca Cran]

On Wednesday, 6 February 2019 12:05:08 MST Laszlo Ersek wrote:

> Is "loader.efi" opaque, or do we know what it does?

It's the FreeBSD loader, so I have the complete source code for it and can 
rebuild it.

> For example, if it opens SNP with BY_DRIVER|EXCLUSIVE attributes, then
> everything on top will be disconnected.

Oh, that makes sense! Thanks, after disabling the existing code that was 
opening SNP exclusively, things started working much better.


-- 
Rebecca Cran

Re: OVMF and TCP4, HTTP protocols

[Rebecca Cran]

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.



— 

Rebecca Cran

Re: OVMF and TCP4, HTTP protocols

[Laszlo Ersek]

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 <mailto: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

Re: OVMF and TCP4, HTTP protocols

[Rebecca Cran]

On 2/12/19 10:44 PM, Laszlo Ersek wrote:
>
> 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.)


Thanks again. Calling CloseProtocol, DisconnectController and then 
ConnectController got things working.


-- 

Rebecca Cran