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 fixed
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 RAM).
Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com>
---
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/e820.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++;
/*
- * Mark populated reserved memory that contains ACPI tables as ACPI data.
+ * Mark populated reserved memory that contains ACPI tables as ACPI NVS.
* 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.
*/
if ( acpi_enabled )
{
e820[nr].addr = RESERVED_MEMBASE;
e820[nr].size = acpi_mem_end - RESERVED_MEMBASE;
- e820[nr].type = E820_ACPI;
+ e820[nr].type = E820_NVS;
nr++;
}
--
2.7.4
