|
From: | Michael Brown |
Subject: | Re: [ipxe-devel] iPXE efi chainloading grub2 pxe efi file |
Date: | Thu, 15 Oct 2015 18:46:19 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
On 14/10/15 07:13, Andrei Borzenkov wrote:
Well, now we have two *applications* each holding exclusive open on adapter. I do not know details about iPXE but if there is any remote chance it does background polling we are back at square one.
iPXE will obtain exclusive access to the underlying SNP, NII, or PCI I/O protocol, and will (quite forcibly) kick off anything else connected to this handle. It will then create an entirely new EFI handle on which is installed iPXE's own SNP and NII protocol instances, along with our own PXEBC and LoadFile protocols. MNP is then allowed to attach to this new handle.
We don't set up a timer for background polling ourselves, but MNP will set up a timer and periodically poll via our provided SNP protocol instance. We forcibly prevent these MNP polls whenever we're in the middle of a blocking operation (such as when shim.efi calls our PXEBC's Mtftp() method).
Hope that helps to explain how iPXE works in some more detail. Please note that all of the above applies only to very recent builds of iPXE (September 2015 onwards).
I have personally observed grub.efi being able to obtain the cached IP address (from our reconstructed DHCP packet) and being able to communicate via the SNP instance provided by iPXE. It _is_ expected to work, and I'm definitely interested in fixing any interoperability problems with GRUB.
Could someone give me a short and simple set of instructions for reproducing the problem being discussed here?
Thanks, Michael
[Prev in Thread] | Current Thread | [Next in Thread] |