From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754729AbcGVNAP (ORCPT ); Fri, 22 Jul 2016 09:00:15 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:36673 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753481AbcGVNAK (ORCPT ); Fri, 22 Jul 2016 09:00:10 -0400 Date: Fri, 22 Jul 2016 14:00:07 +0100 From: Matt Fleming To: Andy Lutomirski Cc: "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner , Mario Limonciello , Kees Cook , "linux-kernel@vger.kernel.org" , Andrew Morton , Matthew Garrett , Peter Zijlstra , X86 ML , Linus Torvalds , Josh Triplett , Peter Jones Subject: Re: [PATCH] x86/boot: Reorganize and clean up the BIOS area reservation code Message-ID: <20160722130007.GI26504@codeblueprint.co.uk> References: <7c190e9b3376002014fb99234ed5e5c64df86322.1469064662.git.luto@kernel.org> <20160721081438.GA26531@gmail.com> <20160721161807.GB30106@gmail.com> 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 Thu, 21 Jul, at 03:45:14PM, Andy Lutomirski wrote: > > I looked at the code some more. The boot services quirk is weird and > maybe buggy. trim_snb_memory uses memblock_reserve to reserve the > bottom 1MB. If efi_reserve_real_mode has already reserved that range, > then trim_snb_memory's reservation will have no effect because the efi > code will just free it later on. The same issue will hit any code > that reserves >1MB memory after efi has tried to temporarily reserve > it. Yeah, that looks like a bug. memblock_reserve() reference counting, anyone? > I don't have any great suggestions for cleaning it up. Perhaps the > efi code should instead skip adding boot services memory to the memory > map in the first place and then add it late and hand any unreserved > bits to the buddy allocator? The issue is that some data required at runtime may be contained in those boot services data regions; the EFI System Resource Table is a good example or the ACPI BGRT table. esrt_init() happens pretty early but efi_bgrt_init() is really late in boot because we need the ACPI subsystem to have been brought up. Fundamentally, you can't know whether you can use the boot services regions for allocation until after SetVirtualAddressMap() has been called (the original bug that required the reservation quirks occurs at SVAM time) and after drivers have read the EFI config tables and marked their regions as reserved. I suppose we could rewrite the page table mapping for those precious <1MB regions to coerce the firmware into accessing different pages instead of the 1:1 addresses and copy the regions elsewhere. Maybe. That assumes we don't hit other firmware bugs though.