Re: [ipxe-devel] iPXE efi chainloading grub2 pxe efi file

[Michael Brown <mcb30@ipxe.org>]

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