From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Zmqes-0007vu-9M for mharc-grub-devel@gnu.org; Thu, 15 Oct 2015 18:05:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zmmbj-0005JR-9g for grub-devel@gnu.org; Thu, 15 Oct 2015 13:46:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zmmbg-0007Zj-2l for grub-devel@gnu.org; Thu, 15 Oct 2015 13:46:27 -0400 Received: from duck.fensystems.co.uk ([212.13.204.60]:53469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zmmbf-0007ZF-Sw for grub-devel@gnu.org; Thu, 15 Oct 2015 13:46:24 -0400 Received: from [10.0.0.133] (cpc3-cmbg15-2-0-cust24.5-4.cable.virginm.net [86.9.148.25]) by duck.fensystems.co.uk (Postfix) with ESMTPSA id C4DBEDA09; Thu, 15 Oct 2015 18:46:20 +0100 (BST) Message-ID: <561FE66B.9080101@ipxe.org> Date: Thu, 15 Oct 2015 18:46:19 +0100 From: Michael Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andrei Borzenkov , "Rivard, Matthew T" , The development of GNU GRUB , ipxe-devel@lists.ipxe.org, edk2-devel-01 Subject: Re: [ipxe-devel] iPXE efi chainloading grub2 pxe efi file References: <55FB8A5F.6040404@gmail.com> <561DF29D.70702@gmail.com> In-Reply-To: <561DF29D.70702@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 212.13.204.60 X-Mailman-Approved-At: Thu, 15 Oct 2015 16:21:54 -0400 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 17:46:29 -0000 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