From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754597AbcGUV2u (ORCPT ); Thu, 21 Jul 2016 17:28:50 -0400 Received: from terminus.zytor.com ([198.137.202.10]:33914 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754355AbcGUV2r (ORCPT ); Thu, 21 Jul 2016 17:28:47 -0400 User-Agent: K-9 Mail for Android In-Reply-To: References: <7c190e9b3376002014fb99234ed5e5c64df86322.1469064662.git.luto@kernel.org> <20160721081438.GA26531@gmail.com> <20160721161807.GB30106@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH] x86/boot: Reorganize and clean up the BIOS area reservation code From: "H. Peter Anvin" Date: Thu, 21 Jul 2016 14:28:16 -0700 To: Andy Lutomirski , Ingo Molnar CC: Matt Fleming , Thomas Gleixner , Mario Limonciello , Kees Cook , "linux-kernel@vger.kernel.org" , Andrew Morton , Matthew Garrett , Peter Zijlstra , X86 ML , Linus Torvalds Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On July 21, 2016 2:08:12 PM PDT, Andy Lutomirski wrote: >On Thu, Jul 21, 2016 at 9:18 AM, Ingo Molnar wrote: >> >> * Andy Lutomirski wrote: >> >>> It would be very easy to implement this if we could handle >overlapping memblocks >>> precisely or set a lower limit on the memblock allocator. Then we >could block >>> off everything below 1MB or 2MB very early and then unblock it or >temporarily >>> change the lower limit and ask for a single page for the trampoline >after that. >> >> So my suggestion was/is to _permanently_ allocate the SMP trampoline >page, and >> leave it also reserved. >> >> 'Reserving' a memory area is really just a kernel internal matter. We >can still >> use it. No need to unreserve/allocate/re-reserve ... unless I'm >missing something. >> > >I don't think you're missing anything particularly deep. I'm just >talking about an implementation issue. We need to make sure that the >page we pick for the trampoline isn't reserved in the memory map or by >some other quirk (including the EBDA). The kernel currently uses >memblock for this, which means that we should probably play nicely >with the memblock code. > >To fix my laptop, though, I think we either need to change the EBDA >reservation (i.e. be willing to pick a page above the EBDA but below >the BIOS) or rework the code so that it can use a BOOT_SERVICES_DATA >page. > >--Andy Oh... this is booting in EFI mode. Now it makes a bit more sense. This is a headache because I believe the same company has put out systems which crash if boot services memory is reclaimed before driver initialization, which is the only reason we can't just treat it as plain memory immediately after invoking ExitBootServices. In theory EBDA in EFI mode is nonsense, too, but not trying to be smart about it might break some systems due to interaction with ACPI. The real mode trampoline code isn't all that large; it is fundamentally limited to 64K but I think it is about 24K right now. This is why we have the 128K "insane" threshold: it is still big enough that we can fit. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.