From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>,
"Jan Beulich" <jbeulich@suse.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Juergen Gross" <jgross@suse.com>
Subject: [PATCH] tools: Mark ACPI SDTs as NVS in the PVH build path
Date: Mon, 10 Mar 2025 15:25:23 +0000 [thread overview]
Message-ID: <20250310152523.81181-1-alejandro.vallejo@cloud.com> (raw)
Commit cefeffc7e583 marked ACPI tables as NVS in the hvmloader path
because SeaBIOS may otherwise just mark it as RAM. There is, however,
yet another reason to do it even in the PVH path. Xen's incarnation of
AML relies on having access to some ACPI tables (e.g: _STA of Processor
objects relies on reading the processor online bit in its MADT entry)
This is problematic if the OS tries to reclaim ACPI memory for page
tables as it's needed for runtime and can't be reclaimed after the OSPM
is up and running.
Fixes: de6d188a519f("hvmloader: flip "ACPI data" to "ACPI NVS" type for ACPI table region)"
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
I really, really, really dislike this idea of accessing the MADT from
AML. In time I'll try to implement something to stop doing it, but for
the time being I find it preferable to align libxl to hvmloader rather
than trying to restrict what's reclaimable and what isn't.
---
tools/firmware/hvmloader/e820.c | 4 ++++
tools/libs/light/libxl_x86.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index c490a0bc790c..86d39544e887 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -210,6 +210,10 @@ int build_e820_table(struct e820entry *e820,
* space reuse by an ACPI unaware / buggy bootloader, option ROM, etc.
* before an ACPI OS takes control. This is possible due to the fact that
* ACPI NVS memory is explicitly described as non-reclaimable in ACPI spec.
+ *
+ * Furthermore, Xen relies on accessing ACPI tables from within the AML
+ * code exposed to guests. So Xen's ACPI tables are not, in general,
+ * reclaimable.
*/
if ( acpi_enabled )
diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
index a3164a3077fe..265da8072a59 100644
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -742,7 +742,7 @@ static int domain_construct_memmap(libxl__gc *gc,
e820[nr].addr = dom->acpi_modules[i].guest_addr_out & ~(page_size - 1);
e820[nr].size = dom->acpi_modules[i].length +
(dom->acpi_modules[i].guest_addr_out & (page_size - 1));
- e820[nr].type = E820_ACPI;
+ e820[nr].type = E820_NVS;
nr++;
}
}
--
2.48.1
next reply other threads:[~2025-03-10 15:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-10 15:25 Alejandro Vallejo [this message]
2025-03-11 8:30 ` [PATCH] tools: Mark ACPI SDTs as NVS in the PVH build path Jan Beulich
2025-03-11 9:17 ` Alejandro Vallejo
2025-03-11 9:23 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250310152523.81181-1-alejandro.vallejo@cloud.com \
--to=alejandro.vallejo@cloud.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.