From nobody Fri Apr 19 07:20:26 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=1602808829; cv=none; d=zohomail.com; s=zohoarc; b=gY8DDeZ7WCOaybwt++8tNrXxNOrHBV7HGPtYYfjQJdzxJQ4S3Fs0lEMSPtwI4MR64mu1Hb6gr8ckxMn2VLl7WYK/H0OfUwyxQqxNd7ryOBezwa1Mv3wK4m2q6OeUE2zG97bEcp5VRfMe2omdQST8K++NMF0snQe35YaQlE/hM/U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1602808829; h=Content-Type:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=AuI7tQv8yS+avgNvkab6iy2nd1B81ALNP17eHCR4lnc=; b=apgHZFUoNek4vGLUI/ZHar/SwOvzzwq/EBP42u5cD2HHrgUK6VVDsD/jh+Sp67Kp8dKlqAJS4ID05OHEZkI6cBoTFVczoagVz1WtfULEnZZkUdqECjdAzG/smS7x1fJyKHQYvRwNM+uOlLwAnkqaw3eV/sgfjO/u3kf+FAoxU8o= 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 1602808829219947.6341404620998; Thu, 15 Oct 2020 17:40:29 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.7750.20399 (Exim 4.92) (envelope-from ) id 1kTDmb-0007FJ-FV; Fri, 16 Oct 2020 00:39:45 +0000 Received: by outflank-mailman (output) from mailman id 7750.20399; Fri, 16 Oct 2020 00:39:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kTDmb-0007FC-At; Fri, 16 Oct 2020 00:39:45 +0000 Received: by outflank-mailman (input) for mailman id 7750; Fri, 16 Oct 2020 00:39: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 1kTDmZ-0007F6-86 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2020 00:39:43 +0000 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 39bd4f66-7deb-4e53-b153-db2ac39a2d1e; Fri, 16 Oct 2020 00:39: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 1kTDmZ-0007F6-86 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2020 00:39:43 +0000 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 39bd4f66-7deb-4e53-b153-db2ac39a2d1e; Fri, 16 Oct 2020 00:39: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: 39bd4f66-7deb-4e53-b153-db2ac39a2d1e DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1602808781; h=from:to:cc:subject:date:message-id:mime-version; bh=A7SS5LkOU52vzc6By7hOafvn87xPxCwRLNNCpbXX8O8=; b=CY/Vb/jCcahcaFT7KBAJv+xxZz5jgjL5y0kfdVEOQ4krZhWAtNji5mCC 1LUEqc8KX7jB0QMdc6PCywd+WZzRSaG2C83pHnQeEksq/0Sw3MAOtNRMz wNmrg9zy8rF32ffpyVRdMmDPgTHuMng8I8zjQZ92EJydWkuHCXwe/kPtI o=; Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: sfdou8sKDvvWTiRJit1Kwt5bCz0OD68kt32J5SZ8stCn13rsb/nbREETUQAygbLmL/P0YAjBBn Eo3GN+g+yMoATm8ZaxgMV2RmgDOA8KpyX5icnNN+EVYs7/qGrKOWH9W5BwntTbcl25pWqJqTMC Uj5ziVpgDwbNPtkiCjh0rFwrCP/8YlnPHuolDoSPwLk2xMPtVn3MiRvMfXf9ia3sU50zXvE121 21SnF6/Sg95mrPynirtJU84xIz8FGEFy4gO3ob82p048jbOp09uUKaCyuUDnAXe5rhmRo6g2Ur n9s= X-SBRS: 2.5 X-MesageID: 29377436 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,380,1596513600"; d="scan'208";a="29377436" From: Igor Druzhinin To: CC: , , , , , Igor Druzhinin Subject: [PATCH v2] hvmloader: flip "ACPI data" to "ACPI NVS" type for ACPI table region Date: Fri, 16 Oct 2020 01:39:23 +0100 Message-ID: <1602808763-22396-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 example is SeaBIOS which currently reports "ACPI data" regions as RAM to the guest in its e801 call. Which it might have the right to do as a= ny user of this is expected to be ACPI unaware. But a QEMU bootloader later se= ems to ignore that fact and is instead using e801 to find a place for initrd wh= ich causes the tables to be erased. While arguably QEMU bootloader or SeaBIOS n= eed to be fixed / improved here, that is just one example of the potential prob= lems from using a 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 Acked-by: Jan Beulich --- Changes in v2: - Put the exact reasoning into a comment - Improved commit message --- tools/firmware/hvmloader/e820.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e82= 0.c index 38bcf18..c490a0b 100644 --- a/tools/firmware/hvmloader/e820.c +++ b/tools/firmware/hvmloader/e820.c @@ -202,16 +202,21 @@ 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. + * + * Using NVS type instead of a regular one helps to prevent potential + * space reuse by an ACPI unaware / buggy bootloader, option ROM, etc. + * before an ACPI OS takes control. This is possible due to the fact t= hat + * ACPI NVS memory is explicitly described as non-reclaimable in ACPI = spec. */ =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