From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754081AbdFWImS (ORCPT ); Fri, 23 Jun 2017 04:42:18 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:33523 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754023AbdFWImO (ORCPT ); Fri, 23 Jun 2017 04:42:14 -0400 Date: Fri, 23 Jun 2017 10:42:10 +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 , Xunlei Pang Subject: Re: [PATCH 1/2][RFC] x86/boot/e820: Introduce e820_table_ori to represent the real original e820 layout Message-ID: <20170623084210.6gn2hqguzfpbvqwi@gmail.com> References: <8082eab4271cfea6f47d190613d09fd3faa9563e.1497675876.git.yu.c.chen@intel.com> <20170622094030.7ge2g2wsvpc6lx5r@gmail.com> <20170623041356.GA28209@yu-desktop-1.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170623041356.GA28209@yu-desktop-1.sh.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: > Hi Ingo, > On Thu, Jun 22, 2017 at 11:40:30AM +0200, Ingo Molnar wrote: > > > > * 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? > > > Both the e820_table and e820_table_firmware will be updated in > e820__reserve_setup_data(): > Changing the PCI device information structures from E820_TYPE_RAM > to E820_TYPE_RESERVED_KERN. > > I.e. what is the point of having 3 different versions of the > > memory layout table? > My original thought was that, we should not record the modification > from the efi boot stub into the e820_tabel_firmware and we are done. > But after checking the code, I realized that if we do so the > kexec might have potiential problem. > > The e820_table_firmware was introduced mainly for kexec and > was used to pass the original memory layout to the second > kernel: > > commit 5dfcf14d5b28174f94cbe9b4fb35d415db61c64a > Author: Bernhard Walle > Date: Fri Jun 27 13:12:55 2008 +0200 > > x86: use FIRMWARE_MEMMAP on x86/E820 > > Besides, the second kernel will not re-enter the efi boot stub > code and it will reuse the PCI device information structure created > by the first kernel, which is stored in the E820_TYPE_RESERVED_KERN > region. So these PCI device information structures will not be > modified by the second kernel, as kexec will only pass the E820_TYPE_RAM > to the second kernel, thus the latter could leverage ioremap to access > the PCI information. > > So the problem is, if we do not record the PCI information in > the e820_table_firmware, the PCI information will be kept as > type E820_TYPE_RAM, and all the E820_TYPE_RAM type regions will > be passed to the second kernel and might be allocated for ordinary > use in the second kernel, as a result the second kernel might not > get valid PCI information(might be overwritten by others). So > currently we try to introduce a new e820_table_ori to represent > the original one provided by the BIOS(mainly for hibernation > memory layout md5 checking). So there's 3 versions we need: - the original 'firmware' table as-is - for MD5 check and other potential purposes - some intermediate version of the table for kexec: what is the exact definition of that table, what changes from the real table does it _not_ want? - the 'real' table all the naming should reflect that. I.e. instead of some nonsensical "_ori" postfix, that is really the _firmware table. If kexec needs a separate one then name it _kexec and copy it at the right stage. Ok? Thanks, Ingo