From nobody Thu Apr 25 05:56:59 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1602586274; cv=none; d=zohomail.com; s=zohoarc; b=fOiZNKNIQq30mWtfbPKJ+CiuJZryoebyA/ilFQIUJtJQ1LjdxMH0eanYwPgHYjB6zwsYbVyb4UMHzUmxZvLImNZKfZjEqsQ3wJuqxIqKaDx0Aty2RlZJKTybHEMIRbXiBJbCk4QsC1dgXKb+xYq9NTC3q0myiIS0QBHZGscq4VA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1602586274; h=Content-Type:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=HE3sudxplrYoFyzeSsWTfr25gh8f14zXHFdW008Vl7Y=; b=fYiO+eyBhnSAkqNOT+vYyUQlLIOiWOtVa/N0VLoazVEvhbrs1Ebo/r8PXhHaVa6jVs79CGfhgpriKUl2pCE+h0EsLdaRyILOmhz1LBbfgAPH6GWp3sAh2nVSjsfsZkX5wzLH8deAuDO8mKZlXXEG2wBkShwoNKqD1ar2Vt7PmeY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 160258627465417.160792449577116; Tue, 13 Oct 2020 03:51:14 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.6149.16206 (Exim 4.92) (envelope-from ) id 1kSHtE-0004rW-UH; Tue, 13 Oct 2020 10:50:44 +0000 Received: by outflank-mailman (output) from mailman id 6149.16206; Tue, 13 Oct 2020 10:50:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kSHtE-0004rP-Qh; Tue, 13 Oct 2020 10:50:44 +0000 Received: by outflank-mailman (input) for mailman id 6149; Tue, 13 Oct 2020 10:50:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kSHtD-0004rJ-Py for xen-devel@lists.xenproject.org; Tue, 13 Oct 2020 10:50:43 +0000 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a3ae139a-c45a-4f3f-86fa-a8fa42e3bb4d; Tue, 13 Oct 2020 10:50:41 +0000 (UTC) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kSHtD-0004rJ-Py for xen-devel@lists.xenproject.org; Tue, 13 Oct 2020 10:50:43 +0000 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a3ae139a-c45a-4f3f-86fa-a8fa42e3bb4d; Tue, 13 Oct 2020 10:50:41 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a3ae139a-c45a-4f3f-86fa-a8fa42e3bb4d DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1602586241; h=from:to:cc:subject:date:message-id:mime-version; bh=bgPSfY5K8mqechUVxCHXmSrJrO0bpaOpkjX5pNnorcI=; b=VBI1Tb6w4bcjWUIv6fwQCLtTJvVKrkNZQt+uYHn8oITs5JO9NJc/u6DS vIH+AH1t9KJz4QTJRuLA4i5D+Abbakc4dx8zJudkpJbUE1oFiWgVWhWrO NPtL06h0N2zqmLIJWPHyzL88AiBbsNVWwK4Wg9BsEr/avPlDMq1WLfaBq A=; Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: toMqVemWoncfsNyagp7tIjtaccWD2ZM0P2gqiQimPUlzyLy7Is/ri76BAspjK4j9vC/qqNQk1n OYrdKId7Dusg/GtjUdYoKIgACrqwTr0+GAP6AnYTVPQtLr6xe0A6wPVayA4kDJxaoZirroMeIi sx411r4Fq4Nvz9MyB5VRr6uWQL8OmsEfF455ipbnshQZFRIqBS1+mwLKv/6YRHMZfFJs2pEw0m QrbqJpTGw5Bd//VQa2lzIb1o55gzSVfDouo52MXGdDG7cwuxcggdUpxGus7y3Qa/vm2YweMA6l uJU= X-SBRS: 2.5 X-MesageID: 29126438 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.77,370,1596513600"; d="scan'208";a="29126438" From: Igor Druzhinin To: CC: , , , , , Igor Druzhinin Subject: [PATCH] hvmloader: flip "ACPI data" to ACPI NVS type for ACPI table region Date: Tue, 13 Oct 2020 11:50:16 +0100 Message-ID: <1602586216-27371-1-git-send-email-igor.druzhinin@citrix.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 X-ZohoMail-DKIM: pass (identity @citrix.com) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" ACPI specification contains statements describing memory marked with regular "ACPI data" type as reclaimable by the guest. Although the guest shouldn't really do it if it wants kexec or similar functionality to work, there could still be ambiguities in treating these regions as potentially regular RAM. One such an example is SeaBIOS which currently reports "ACPI data" regions = as RAM to the guest in its e801 call. The guest then tries to use this region for initrd placement and gets stuck. While arguably SeaBIOS needs to be fix= ed here, that is just one example of the potential problems from using reclaimable memory type. Flip the type to "ACPI NVS" which doesn't have this ambiguity in it and is described by the spec as non-reclaimable (so cannot ever be treated like RA= M). Signed-off-by: Igor Druzhinin --- tools/firmware/hvmloader/e820.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e82= 0.c index 38bcf18..8870099 100644 --- a/tools/firmware/hvmloader/e820.c +++ b/tools/firmware/hvmloader/e820.c @@ -202,16 +202,17 @@ int build_e820_table(struct e820entry *e820, nr++; =20 /* - * Mark populated reserved memory that contains ACPI tables as ACPI da= ta. + * Mark populated reserved memory that contains ACPI tables as ACPI NV= S. * That should help the guest to treat it correctly later: e.g. pass to - * the next kernel on kexec or reclaim if necessary. + * the next kernel on kexec and prevent space reclaim which is possible + * with regular ACPI data type accoring to ACPI spec v6.3. */ =20 if ( acpi_enabled ) { e820[nr].addr =3D RESERVED_MEMBASE; e820[nr].size =3D acpi_mem_end - RESERVED_MEMBASE; - e820[nr].type =3D E820_ACPI; + e820[nr].type =3D E820_NVS; nr++; } =20 --=20 2.7.4