From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YLSWq-0004cL-7a for mharc-grub-devel@gnu.org; Wed, 11 Feb 2015 03:20:12 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLSWo-0004cE-2l for grub-devel@gnu.org; Wed, 11 Feb 2015 03:20:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLSWk-00007y-TZ for grub-devel@gnu.org; Wed, 11 Feb 2015 03:20:10 -0500 Received: from mail.emea.novell.com ([130.57.118.101]:40749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLSWk-00005J-Li for grub-devel@gnu.org; Wed, 11 Feb 2015 03:20:06 -0500 Received: from EMEA1-MTA by mail.emea.novell.com with Novell_GroupWise; Wed, 11 Feb 2015 08:20:05 +0000 Message-Id: <54DB1EC4020000780005EDDB@mail.emea.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.0.1 Date: Wed, 11 Feb 2015 08:20:04 +0000 From: "Jan Beulich" To: "Daniel Kiper" Subject: Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms References: <1422640462-28103-1-git-send-email-daniel.kiper@oracle.com> <1422640462-28103-19-git-send-email-daniel.kiper@oracle.com> <20150210212749.GG2227@olila.local.net-space.pl> In-Reply-To: <20150210212749.GG2227@olila.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.57.118.101 Cc: Juergen Gross , grub-devel@gnu.org, keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, roy.franz@linaro.org, ning.sun@intel.com, david.vrabel@citrix.com, phcoder@gmail.com, xen-devel@lists.xenproject.org, qiaowei.ren@intel.com, richard.l.maliszewski@intel.com, gang.wei@intel.com, fu.wei@linaro.org 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: Wed, 11 Feb 2015 08:20:11 -0000 >>> On 10.02.15 at 22:27, wrote: > After some testing we have found at least one machine on which this = thing > does not work. It is Dell PowerEdge R820 with latest firmware. Machine > crashes/stops because early 32-bit code is not relocatable and must live > under 0x100000 address. (side note: I am surprised how it worked without > any issue until now; Multiboot protocol, any version, does not guarantee > that OS image will be loaded at specified/requested address; How does it not? It's an ELF binary without relocations that's being loaded - I can't see how such could be validly loaded anywhere but at the virtual address(es) its program header states (and I don't know whether grub [1 or 2] would correctly process relocations if there were any, but I doubt it). > Now I see two solutions for these issues: >=20 > 1) We can make early 32-bit code relocatable. We may use something = similar > to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I = think > that early code should not blindly map first 16 MiB of memory. It = should > map first 1 MiB of memory and then 16 MiB of memory starting from > xen_phys_start. This way we also fix long standing bug in early code > which I described earlier. >=20 > 2) We can jump from EFI x86-64 mode directly into "Xen x86-64 mode" like > it is done in case of EFI loader. However, then we must duplicate=20 > multiboot2 > protocol implementation in x86-64 mode (if we wish that multiboot2=20 > protocol > can be used on legacy BIOS and EFI platforms; I think that we = should=20 > support > this protocol on both for users convenience). Additionally, we must = use > a workaround to relocate trampoline if boot services uses memory = below 1=20 > MiB > (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, = x86/EFI:=20 > make > trampoline allocation more flexible, for more details). >=20 > I prefer #1 because this way we do not duplicate multiboot2 protocol=20 > implementation > (one for legacy BIOS and EFI) and we avoid issues with trampoline = relocation=20 > when > low memory is occupied by boot services and/or 1:1 EFI page tables. Between the two, 1 is certainly the preferable option. > PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d97= 13d > will not work if trampoline code will overwrite some of EFI 1:1 = page=20 > tables. > Dell PowerEdge R820 store part of 1:1 page tables below 1 MiB. Xen = loaded > by native EFI loader boots but it is only lucky coincidence that it = does > not overwrite used entries. So, I tend to go and choose #1 even more. How awful a firmware implementation! On PC-like systems, _nothing_ that _absolutely_ has to be below 1Mb should be placed there. Jan