From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YMgRk-0007IX-1Z for mharc-grub-devel@gnu.org; Sat, 14 Feb 2015 12:24:00 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMgRe-0007ID-F4 for grub-devel@gnu.org; Sat, 14 Feb 2015 12:23:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMgRZ-0006DG-Gg for grub-devel@gnu.org; Sat, 14 Feb 2015 12:23:54 -0500 Received: from mail-la0-f49.google.com ([209.85.215.49]:46341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMgRZ-0006Cp-70 for grub-devel@gnu.org; Sat, 14 Feb 2015 12:23:49 -0500 Received: by lams18 with SMTP id s18so21822071lam.13 for ; Sat, 14 Feb 2015 09:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=8PSP/ZUSsixOpAZk55BpUaQnxgrwZvU8BWFuM4N1Dek=; b=ynPyHhwcc3rymkG+UmzmW86nA+a3fVgu4jmbgAX5xAxkNYhkaFrlhQzHmTgwLf2ERP 1Td95kTjpYKAOmaez/WvTY1uIFXnPk43b3nERtimf2t5TIN+v0WMHNgYo8lnXA9rvfBF NZNbGnpPrb9h/P1onYLk40D5A+Bc1iDxKVy38gZunweTW0Q7JpFwqU+3kmKgeQC5esIP bQpYsXMu8dxqaSOZFlmZYsr/nV0fKVz+vUn36qbK8HROu1ViYArv1nVKBuka7n0Xnn1I 1DNWnUIMpMY/T5iq2hysswBRWI3/AwwH3QRnoSNGwRFMEQapp/2G0s7Bz8TiNO6BdpVW LFqw== X-Received: by 10.112.185.101 with SMTP id fb5mr13989989lbc.12.1423934628584; Sat, 14 Feb 2015 09:23:48 -0800 (PST) Received: from opensuse.site (ppp91-76-14-38.pppoe.mtu-net.ru. [91.76.14.38]) by mx.google.com with ESMTPSA id pq1sm405063lbb.41.2015.02.14.09.23.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Feb 2015 09:23:47 -0800 (PST) Date: Sat, 14 Feb 2015 20:23:45 +0300 From: Andrei Borzenkov To: "Jan Beulich" Subject: Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms Message-ID: <20150214202345.4c71bead@opensuse.site> In-Reply-To: <54DB1EC4020000780005EDDB@mail.emea.novell.com> 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> <54DB1EC4020000780005EDDB@mail.emea.novell.com> X-Mailer: Claws Mail 3.11.0 (GTK+ 2.24.25; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.215.49 Cc: Juergen Gross , grub-devel@gnu.org, keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, Daniel Kiper , 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: Sat, 14 Feb 2015 17:23:59 -0000 =D0=92 Wed, 11 Feb 2015 08:20:04 +0000 "Jan Beulich" =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>> On 10.02.15 at 22:27, wrote: > > After some testing we have found at least one machine on which this thi= ng > > 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; >=20 > 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). >=20 grub2 relocates own modules when loading them. It does not do relocation when loading Xen binary, but it does not sound impossible. > > Now I see two solutions for these issues: > >=20 > > 1) We can make early 32-bit code relocatable. We may use something simi= lar > > to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I thi= nk > > that early code should not blindly map first 16 MiB of memory. It sh= ould > > 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 bel= ow 1=20 > > MiB > > (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, x86/E= FI:=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 reloc= ation=20 > > when > > low memory is occupied by boot services and/or 1:1 EFI page tables. >=20 > Between the two, 1 is certainly the preferable option. >=20 > > PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d= 9713d > > 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 l= oaded > > 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. >=20 > How awful a firmware implementation! On PC-like systems, _nothing_ > that _absolutely_ has to be below 1Mb should be placed there. >=20 > Jan >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel