[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2] tools: Mark ACPI SDTs as NVS in the PVH build path
On 11.03.2025 10:29, Alejandro Vallejo wrote: > 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@xxxxxxxxx> > --- > v1->v2: > * Copy explanatory comment in hvmloader/e820.c to its libxl_x86.c > counterpart > > --- > tools/firmware/hvmloader/e820.c | 4 ++++ > tools/libs/light/libxl_x86.c | 17 ++++++++++++++++- > 2 files changed, 20 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..2ba96d12e595 100644 > --- a/tools/libs/light/libxl_x86.c > +++ b/tools/libs/light/libxl_x86.c > @@ -737,12 +737,27 @@ static int domain_construct_memmap(libxl__gc *gc, > nr++; > } > > + /* > + * 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. > + * > + * 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 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. > + */ When asking for a comment here I really only was after what the last paragraph says. Especially the middle paragraph seems questionable to me: It would not only be ACPI- unawareness, but also E820-unawareness, for the range to be prematurely re-used. And buggy bootloaders really would need fixing, I think - they'd put OSes into trouble on real hardware as well. In short - I'd like to ask that the middle paragraph be dropped from here (which surely could be done while committing). However, there's a second concern: You say "PVH" in the title, yet this function is in use also for HVM, and ... > for (i = 0; i < MAX_ACPI_MODULES; i++) { > if (dom->acpi_modules[i].length) { > 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++; > } > } ... this code is outside of any conditionals. This imo needs sorting one way or another. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |