From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753037AbdFVJkf (ORCPT ); Thu, 22 Jun 2017 05:40:35 -0400 Received: from mail-wr0-f195.google.com ([209.85.128.195]:32935 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752755AbdFVJke (ORCPT ); Thu, 22 Jun 2017 05:40:34 -0400 Date: Thu, 22 Jun 2017 11:40:30 +0200 From: Ingo Molnar To: Chen Yu Cc: x86@kernel.org, linux-kernel@vger.kernel.org, "Rafael J . Wysocki" , Ingo Molnar , Thomas Gleixner , Len Brown , Ying Huang Subject: Re: [PATCH 1/2][RFC] x86/boot/e820: Introduce e820_table_ori to represent the real original e820 layout Message-ID: <20170622094030.7ge2g2wsvpc6lx5r@gmail.com> References: <8082eab4271cfea6f47d190613d09fd3faa9563e.1497675876.git.yu.c.chen@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8082eab4271cfea6f47d190613d09fd3faa9563e.1497675876.git.yu.c.chen@intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Chen Yu wrote: > Currently we try to have e820_table_firmware to represent the > original firmware memory layout passed to us by the bootloader, > however it is not the case, the e820_table_firmware might still > be modified by linux: > 1. During bootup, the efi boot stub might allocate memory via > efi service for the PCI device information structure, then > later e820_reserve_setup_data() reserved these dynamically > allocated structures(AKA, setup_data) in e820_table_firmware > accordingly. > 2. The kexec might also modify the e820_table_firmware. Hm, so why does the EFI code modify e280_table_firmware - why doesn't it modify e820_table? I.e. what is the point of having 3 different versions of the memory layout table? Thanks, Ingo