Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2136738yba; Fri, 19 Apr 2019 12:54:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqw8IAUW4N4KLE5+PJlNUw+bXrho+a9VdXWZKYBxH6vidHKppY9p8gTcNhTIkHGi8A6P94MI X-Received: by 2002:a17:902:8d83:: with SMTP id v3mr5687156plo.283.1555703641155; Fri, 19 Apr 2019 12:54:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555703641; cv=none; d=google.com; s=arc-20160816; b=GPG3fe7pO77Dpw1fivuoraqroQeQWKAT6wGKIiu+jaaEehiyjnlTM37pyvaNR0KkeH 3mpuSFBm0ye7arxBPd6BIHJnOqf5VNAcF+PxxaY2FkpDmAocXpjjQ1qcey65BXdYVV2J qt4NOV1whxvmj6OBzYmwnpds58h7cjgbUynSHL1cScKtWViPuTJPl1pdD1uCM0j9dpN+ gr6Sjp8QNGDJZlbagi90bvldHbgjCr5N4Klarm2px6gp6mrA5iAkuh3zVOBksk+1hys/ wBtdNRXI1/R35ZqTpSjmXXNyTACmkYVVzLe9SiSfWrTs91x9Z4qxMu/I/6Awsa+Txkdk CP+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=EquybNfivVd7iyASULDNQsV8V7M9xg3yLB6OIuuy8BU=; b=ig7Z5Msp3j52+AaPuGmw8PMNvflAi9NvWYDbozRmMgq6baM1nZABtCKcAE4/jPpkl0 OeUpT5eDRZHYJi/aI+0cRMw6N9qM5o+XHNLAaiG5qfFpDpq/SW1tgwstJztFVKT2QgfQ RuqOpOKJuaYdiK1x97FW8CFijQfiATurXZk0or145nJvR4ZfGPYF/GQkghqiA+N64+t/ ADkjUshku7Gtm+0QkjS+Wfq9eZJCZgFzl2z9GqvQGckKW+gIebvqIEvjxP8jwXvLQio2 rSbyhO6lUHC5/dyrTG8fmvxFZvM0v2l9nF818wN0RWG50FYgLfl2gxDNCE7w51Z9nKtT sfYA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q9si5823030pll.41.2019.04.19.12.53.45; Fri, 19 Apr 2019 12:54:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727466AbfDSTwu (ORCPT + 99 others); Fri, 19 Apr 2019 15:52:50 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:43166 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726174AbfDSTwu (ORCPT ); Fri, 19 Apr 2019 15:52:50 -0400 Received: by mail-io1-f65.google.com with SMTP id x3so5164276iol.10 for ; Fri, 19 Apr 2019 12:52:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EquybNfivVd7iyASULDNQsV8V7M9xg3yLB6OIuuy8BU=; b=qRj/vZ4t0t/yskOfDgo+mNip87NOLswGkRUjiAK1TmUsxm1zEoaytzWOfFfJBFr9L6 useVXofo5YbJEdVTWzvKVEstunf478PeAlY2fXlpLF+YlxUSe9djSQxWe4Cu+WiTqh91 mElWG/5Rjg1Ni9IVSMSJ5YJQEvGgMeBfVC3qPIUgVairnKge9ewKHE0HemxETz0UhhjC nk2nybQTAO9z6NtglWZMromXuOqSpcA8V3/XuzsZwMLlLlOE+4nwlZ64XAVHC0X/OPKM ELxmX1FU8Xi3bO1oVUUARwFTs8RIuh80uEriPj/1oKhjy6Xk0aXiH1lw8UNu1fAO0Yrr 4J3Q== X-Gm-Message-State: APjAAAVvSEdfIz1AXsn1Gwp9z01SIRGMOhJYKXrUfREliRbgDdDjqlFF 854iT8urBUpNZw6OeUAhFx1+IT9rpk41ZnLjjyaOWHhhvVN4qA== X-Received: by 2002:a6b:6509:: with SMTP id z9mr1913841iob.43.1555666779770; Fri, 19 Apr 2019 02:39:39 -0700 (PDT) MIME-Version: 1.0 References: <20190416095209.GG27892@zn.tnic> <20190419083458.503-1-kasong@redhat.com> <20190419085804.GD11060@MiWiFi-R3L-srv> In-Reply-To: <20190419085804.GD11060@MiWiFi-R3L-srv> From: Kairui Song Date: Fri, 19 Apr 2019 17:39:28 +0800 Message-ID: Subject: Re: [RFC PATCH] kexec, x86/boot: map systab region in identity mapping before accessing it To: Baoquan He Cc: Linux Kernel Mailing List , Borislav Petkov , Junichi Nomura , Dave Young , Chao Fan , "x86@kernel.org" , "kexec@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 19, 2019 at 4:58 PM Baoquan He wrote: > > On 04/19/19 at 04:34pm, Kairui Song wrote: > > /* Locates and clears a region for a new top level page table. */ > > void initialize_identity_maps(void) > > { > > - /* If running as an SEV guest, the encryption mask is required. */ > > - set_sev_encryption_mask(); > > - > > - /* Exclude the encryption mask from __PHYSICAL_MASK */ > > - physical_mask &= ~sme_me_mask; > > - > > - /* Init mapping_info with run-time function/buffer pointers. */ > > - mapping_info.alloc_pgt_page = alloc_pgt_page; > > - mapping_info.context = &pgt_data; > > - mapping_info.page_flag = __PAGE_KERNEL_LARGE_EXEC | sme_me_mask; > > - mapping_info.kernpg_flag = _KERNPG_TABLE; > > - > > - /* > > - * It should be impossible for this not to already be true, > > - * but since calling this a second time would rewind the other > > - * counters, let's just make sure this is reset too. > > - */ > > - pgt_data.pgt_buf_offset = 0; > > - > > - /* > > - * If we came here via startup_32(), cr3 will be _pgtable already > > - * and we must append to the existing area instead of entirely > > - * overwriting it. > > - * > > - * With 5-level paging, we use '_pgtable' to allocate the p4d page table, > > - * the top-level page table is allocated separately. > > - * > > - * p4d_offset(top_level_pgt, 0) would cover both the 4- and 5-level > > - * cases. On 4-level paging it's equal to 'top_level_pgt'. > > - */ > > - top_level_pgt = read_cr3_pa(); > > - if (p4d_offset((pgd_t *)top_level_pgt, 0) == (p4d_t *)_pgtable) { > > - debug_putstr("booted via startup_32()\n"); > > - pgt_data.pgt_buf = _pgtable + BOOT_INIT_PGT_SIZE; > > - pgt_data.pgt_buf_size = BOOT_PGT_SIZE - BOOT_INIT_PGT_SIZE; > > - memset(pgt_data.pgt_buf, 0, pgt_data.pgt_buf_size); > > - } else { > > - debug_putstr("booted via startup_64()\n"); > > - pgt_data.pgt_buf = _pgtable; > > - pgt_data.pgt_buf_size = BOOT_PGT_SIZE; > > - memset(pgt_data.pgt_buf, 0, pgt_data.pgt_buf_size); > > + top_level_pgt = early_boot_top_pgt; > > + if ((p4d_t *)top_level_pgt != (p4d_t *)_pgtable) > > top_level_pgt = (unsigned long)alloc_pgt_page(&pgt_data); > > Kairui, will you make a patchset to include these changes separately > later on? I don't get the purposes of code changes. E.g here, I > don't know why you introduce a new variable early_boot_top_pgt, and > allocate the page table, even though they have been done in the old > initialize_identity_maps(). > > Thanks > Baoquan > OK, right, it's not a good idea to mess up things together, I'll resend the patch, and will sent the cleanup separately. Without clean up it may bring in some extra burden with certain kernel config, but that should be OK for the fix. -- Best Regards, Kairui Song