From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CAAFC433E2 for ; Fri, 4 Sep 2020 11:49:49 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1F2B620C56 for ; Fri, 4 Sep 2020 11:49:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="A/fdHqAa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F2B620C56 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kEADS-0001n5-TR; Fri, 04 Sep 2020 11:49:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kEADS-0001n0-9c for xen-devel@lists.xenproject.org; Fri, 04 Sep 2020 11:49:14 +0000 X-Inumbo-ID: 9ed03eb3-805b-42e6-b7fe-e966087d33d1 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9ed03eb3-805b-42e6-b7fe-e966087d33d1; Fri, 04 Sep 2020 11:49:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1599220152; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4R5zIg/3MzyjR2OkAka+osy6n2T0o2xGwduHqT2979M=; b=A/fdHqAa7DOnBVfyskaq4iuDODrcEmYzb8W083FnMY3Qkqvf0VL0orNS zjb7UtsPxyCD1uBl2waQaXjYVvWQW//xkpV5BWg6TgbmfKJythhqb804w IP0CAmcvUT4j8D9zNCqokCwEjN5WuL3QUoIuiTmCeX+0SIYEaaHMvOB21 g=; Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 23QSXyPBW+PDd2+Ntza60esVbL7czRC2ZZOFKkPM7KLx20ivB6BDKtmczad+W2UyAEmYt8Zf5K dIPELTp1e2hx4JWvBrM59EwBU6025bKIJZZwM7quXilePOr4PJqHDvzAMhqAaDRBcTk4VZUk0M 9UkCpGo/G+BMJDN4ehrxSNAPjzPnRYC3t03OPxH5RSif2jNmlaO1RDUlM3JxnS91ZpUvWdWZI+ 0qyRjpLNg87DUO7P3O22jtOK2fDA2NM/6p5uB2t+Hu/Ayl6cNSFNRswCWyo/iObt17swtGoxMO w8k= X-SBRS: 2.7 X-MesageID: 26129060 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.76,389,1592884800"; d="scan'208";a="26129060" Subject: Re: [PATCH v2.1] hvmloader: indicate dynamically allocated memory as ACPI NVS in e820 To: Jan Beulich CC: , , , , References: <1598928634-30849-1-git-send-email-igor.druzhinin@citrix.com> From: Igor Druzhinin Message-ID: <17fb8575-8a05-9c31-b777-292b66b0e7e1@citrix.com> Date: Fri, 4 Sep 2020 12:49:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/09/2020 09:33, Jan Beulich wrote: > On 01.09.2020 04:50, Igor Druzhinin wrote: >> Guest kernel does need to know in some cases where the tables are located >> to treat these regions properly. One example is kexec process where >> the first kernel needs to pass firmware region locations to the second >> kernel which is now a requirement after 02a3e3cdb7f12 ("x86/boot: Parse SRAT >> table and count immovable memory regions"). > > I'm still struggling with the connection here: Reserved regions > surely are "immovable" too, aren't they? "Immovable" regions here are RAM that doesn't go away by hot-unplug. That change was necessary in Linux to avoid image randomized placement to these regions. > Where's the connection to > the E820 map in the first place - the change cited above is entirely > about SRAT? And I can't imagine kexec getting away with passing on > ACPI NVS regions, but not reserved ones. > They got away with it for as long as kexec exists I think. The point was that those reserved regions were not accessed during early boot as long as kexec kernel stays at transition tables. Now ACPI portion of it is accessed which highlighted our imprecise reporting of memory layout to the guest - which I think should be fixed either way. I'm not going to argue if reserved regions should be mapped to transition tables or not - I don't think it's important in context related to this patch. There were already several kernel releases without that mappings and those also should be able to invoke kdump. Igor