From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VYesZ-00059F-4v for mharc-grub-devel@gnu.org; Tue, 22 Oct 2013 12:32:23 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYesP-00057q-1R for grub-devel@gnu.org; Tue, 22 Oct 2013 12:32:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYesG-0000RO-FU for grub-devel@gnu.org; Tue, 22 Oct 2013 12:32:12 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:21329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYesG-0000RK-7r for grub-devel@gnu.org; Tue, 22 Oct 2013 12:32:04 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9MGVwoL003751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Oct 2013 16:31:59 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9MGVvgi005769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Oct 2013 16:31:58 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9MGVvDA014983; Tue, 22 Oct 2013 16:31:57 GMT Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Oct 2013 09:31:56 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5A3FC1C253F; Tue, 22 Oct 2013 12:31:55 -0400 (EDT) Date: Tue, 22 Oct 2013 12:31:55 -0400 From: Konrad Rzeszutek Wilk To: "Vladimir =?utf-8?Q?'=CF=86-coder=2Fphcoder'?= Serbinenko" Subject: Re: EFI and multiboot2 devlopment work for Xen Message-ID: <20131022163155.GC19189@phenom.dumpdata.com> References: <1382433990.1657.66.camel@hastur.hellion.org.uk> <5266620602000078000FCA48@nat28.tlf.novell.com> <1382435127.1657.70.camel@hastur.hellion.org.uk> <526668A502000078000FCA7B@nat28.tlf.novell.com> <20131022134252.GA27302@phenom.dumpdata.com> <1382449985.18283.12.camel@hastur.hellion.org.uk> <20131022140947.GA17829@phenom.dumpdata.com> <1382451868.18283.21.camel@hastur.hellion.org.uk> <20131022145140.GA18679@phenom.dumpdata.com> <52669C2C.90509@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <52669C2C.90509@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 Cc: The development of GNU GRUB , keir@xen.org, Ian Campbell , stefano.stabellini@eu.citrix.com, Daniel Kiper , linux-kernel@vger.kernel.org, xen-devel@lists.xen.org, Jan Beulich , ross.philipson@citrix.com, richard.l.maliszewski@intel.com, boris.ostrovsky@oracle.com, david.woodhouse@intel.com 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: Tue, 22 Oct 2013 16:32:21 -0000 On Tue, Oct 22, 2013 at 05:39:24PM +0200, Vladimir '=CF=86-coder/phcoder'= Serbinenko wrote: > On 22.10.2013 16:51, Konrad Rzeszutek Wilk wrote: > > If you use 'linux' module, it will call ExitBootService. > > If you use 'multiboot' module, it will call ExitBootService too. > >=20 > > So if you don't want to the module to call 'grub_efi_finish_boot_serv= ices' > > you need to use 'linuxefi' :-) > That's a very limited logic. Commands can be modified and protocols can > be extended. > There was only one e-mail explaining the needs and I answered with > proposing possible solutions yet the 2 e-mails in question were > completely ignored. This was before my time - so I am not exactly sure what was discussed. You wouldn't by any chance have any URLs handy? > What's the need behind not calling ExitBootService? This is a point > which was never really explained to me. EFI specification specifically > tells to call ExitBootService. This commit points to it being a problem with the spec and hardware implementations not being in sync: commit 916f676f8dc016103f983c7ec54c18ecdbb6e349 Author: Matthew Garrett Date: Wed May 25 09:53:13 2011 -0400 x86, efi: Retain boot service code until after switching to virtual m= ode =20 UEFI stands for "Unified Extensible Firmware Interface", where "Firmw= are" is an ancient African word meaning "Why do something right when you c= an do it so wrong that children will weep and brave adults will cower be= fore you", and "UEI" is Celtic for "We missed DOS so we burned it into you= r ROMs". The UEFI specification provides for runtime services (ie, anot= her way for the operating system to be forced to depend on the firmware) = and we rely on these for certain trivial tasks such as setting up the bootloader. But some hardware fails to work if we attempt to use thes= e runtime services from physical mode, and so we have to switch into vi= rtual mode. So far so dreadful. =20 The specification makes it clear that the operating system is free to= do whatever it wants with boot services code after ExitBootServices() ha= s been called. SetVirtualAddressMap() can't be called until ExitBootServices= () has been. So, obviously, a whole bunch of EFI implementations call into b= oot services code when we do that. Since we've been charmingly naive and trusted that the specification may be somehow relevant to the real wo= rld, we've already stuffed a picture of a penguin or something in that add= ress space. And just to make things more entertaining, we've also marked i= t non-executable. =20 This patch allocates the boot services regions during EFI init and ma= kes sure that they're executable. Then, after SetVirtualAddressMap(), it discards them and everyone lives happily ever after. Except for the o= nes who have to work on EFI, who live sad lives haunted by the knowledge = that someone's eventually going to write yet another firmware specificatio= n. =20 [ hpa: adding this to urgent with a stable tag since it fixes current= ly-broken hardware. However, I do not know what the dependencies are and so = I do not know which -stable versions this may be a candidate for. ] =20 Signed-off-by: Matthew Garrett Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@= redhat.com >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754466Ab3JVQcf (ORCPT ); Tue, 22 Oct 2013 12:32:35 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:28358 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752787Ab3JVQce convert rfc822-to-8bit (ORCPT ); Tue, 22 Oct 2013 12:32:34 -0400 Date: Tue, 22 Oct 2013 12:31:55 -0400 From: Konrad Rzeszutek Wilk To: "Vladimir =?utf-8?Q?'=CF=86-coder=2Fphcoder'?= Serbinenko" Cc: The development of GNU GRUB , Ian Campbell , keir@xen.org, david.woodhouse@intel.com, stefano.stabellini@eu.citrix.com, Daniel Kiper , linux-kernel@vger.kernel.org, xen-devel@lists.xen.org, Jan Beulich , ross.philipson@citrix.com, boris.ostrovsky@oracle.com, richard.l.maliszewski@intel.com Subject: Re: EFI and multiboot2 devlopment work for Xen Message-ID: <20131022163155.GC19189@phenom.dumpdata.com> References: <1382433990.1657.66.camel@hastur.hellion.org.uk> <5266620602000078000FCA48@nat28.tlf.novell.com> <1382435127.1657.70.camel@hastur.hellion.org.uk> <526668A502000078000FCA7B@nat28.tlf.novell.com> <20131022134252.GA27302@phenom.dumpdata.com> <1382449985.18283.12.camel@hastur.hellion.org.uk> <20131022140947.GA17829@phenom.dumpdata.com> <1382451868.18283.21.camel@hastur.hellion.org.uk> <20131022145140.GA18679@phenom.dumpdata.com> <52669C2C.90509@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <52669C2C.90509@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: 8BIT X-Source-IP: acsinet22.oracle.com [141.146.126.238] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 22, 2013 at 05:39:24PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 22.10.2013 16:51, Konrad Rzeszutek Wilk wrote: > > If you use 'linux' module, it will call ExitBootService. > > If you use 'multiboot' module, it will call ExitBootService too. > > > > So if you don't want to the module to call 'grub_efi_finish_boot_services' > > you need to use 'linuxefi' :-) > That's a very limited logic. Commands can be modified and protocols can > be extended. > There was only one e-mail explaining the needs and I answered with > proposing possible solutions yet the 2 e-mails in question were > completely ignored. This was before my time - so I am not exactly sure what was discussed. You wouldn't by any chance have any URLs handy? > What's the need behind not calling ExitBootService? This is a point > which was never really explained to me. EFI specification specifically > tells to call ExitBootService. This commit points to it being a problem with the spec and hardware implementations not being in sync: commit 916f676f8dc016103f983c7ec54c18ecdbb6e349 Author: Matthew Garrett Date: Wed May 25 09:53:13 2011 -0400 x86, efi: Retain boot service code until after switching to virtual mode UEFI stands for "Unified Extensible Firmware Interface", where "Firmware" is an ancient African word meaning "Why do something right when you can do it so wrong that children will weep and brave adults will cower before you", and "UEI" is Celtic for "We missed DOS so we burned it into your ROMs". The UEFI specification provides for runtime services (ie, another way for the operating system to be forced to depend on the firmware) and we rely on these for certain trivial tasks such as setting up the bootloader. But some hardware fails to work if we attempt to use these runtime services from physical mode, and so we have to switch into virtual mode. So far so dreadful. The specification makes it clear that the operating system is free to do whatever it wants with boot services code after ExitBootServices() has been called. SetVirtualAddressMap() can't be called until ExitBootServices() has been. So, obviously, a whole bunch of EFI implementations call into boot services code when we do that. Since we've been charmingly naive and trusted that the specification may be somehow relevant to the real world, we've already stuffed a picture of a penguin or something in that address space. And just to make things more entertaining, we've also marked it non-executable. This patch allocates the boot services regions during EFI init and makes sure that they're executable. Then, after SetVirtualAddressMap(), it discards them and everyone lives happily ever after. Except for the ones who have to work on EFI, who live sad lives haunted by the knowledge that someone's eventually going to write yet another firmware specification. [ hpa: adding this to urgent with a stable tag since it fixes currently-broken hardware. However, I do not know what the dependencies are and so I do not know which -stable versions this may be a candidate for. ] Signed-off-by: Matthew Garrett Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.com >