[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]