From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752076AbcGaVi3 (ORCPT ); Sun, 31 Jul 2016 17:38:29 -0400 Received: from mail-wm0-f42.google.com ([74.125.82.42]:35169 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751329AbcGaViU (ORCPT ); Sun, 31 Jul 2016 17:38:20 -0400 Date: Sun, 31 Jul 2016 22:38:17 +0100 From: Matt Fleming To: Andy Lutomirski Cc: "H. Peter Anvin" , x86@kernel.org, Mario Limonciello , Matthew Garrett , Borislav Petkov , Matt Fleming , linux-kernel@vger.kernel.org Subject: Re: [PATCH 4.8? 0/4] Allow the trampoline to use EFI boot services RAM Message-ID: <20160731213817.GC3636@codeblueprint.co.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 26 Jul, at 03:55:24PM, Andy Lutomirski wrote: > As currently configured, my laptop cannot boot any existing kernel > because the real mode trampoline can't be reserved. The ranges in > which it could live are rejected by the kernel: one is EFI boot > services data and the other is above the EBDA. > > Allowing use of RAM between the EBDA and 640k is scary: there are > probably many quirky BIOSes out there, and, as currently structured, > it would be awkward to allow it just on EFI boots because we > currently reserve that range before we figure out whether we're > using EFI. > > This series fixes it the other way: it allow the trampoline to live > in boot services memory. It achieves this by deferring the panic > due to failure to reserve a trampoline until early_initcall time > and then adjusting the EFI boot services quirk to reserve space > for the trampoline if we haven't already found it a home. > > I'm hoping this is okay for 4.8 even though it's late: it fixes > a boot failure and it's fairly conservative -- the only significant > changes in behavior should be on systems that currently fail to boot. > > I'm not currently proposing it for stable because AFAIK I'm the > only person to have seen this issue. If it survives in Linus' > tree for a while, though, I might propose it for -stable later > on. I took a very, very quick look over this series and nothing jumped out as being wrong. I'll take a much closer look this week.