Now that BGRT images are preserved during EFI boot (via
EfiACPIReclaimMemory allocation), the invalidation code in
acpi_parse_bgrt() is no longer needed. The BGRT table remains
valid throughout boot.

This removes the code that was marking BGRT invalid when the
image memory was detected as unavailable, which was causing
ACPI warnings in Linux dom0.

Signed-off-by: Soumyajyotii Ssarkar <soumyajyotisarkar23@gmail.com>
---
 xen/arch/x86/acpi/boot.c | 23 -----------------------
 1 file changed, 23 deletions(-)

diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c
index 1ca2360e00..fc88b559e6 100644
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -327,27 +327,6 @@ static int __init cf_check acpi_parse_hpet(struct acpi_table_header *table)
 	return 0;
 }

-static int __init cf_check acpi_invalidate_bgrt(struct acpi_table_header *table)
-{
-	struct acpi_table_bgrt *bgrt_tbl =
-		container_of(table, struct acpi_table_bgrt, header);
-
-	if (table->length < sizeof(*bgrt_tbl))
-		return -1;
-
-	if (bgrt_tbl->version == 1 && bgrt_tbl->image_address
-	    && !page_is_ram_type(PFN_DOWN(bgrt_tbl->image_address),
-				 RAM_TYPE_CONVENTIONAL))
-		return 0;
-
-	printk(KERN_INFO PREFIX "BGRT: invalidating v%d image at %#"PRIx64"\n",
-	       bgrt_tbl->version, bgrt_tbl->image_address);
-	bgrt_tbl->image_address = 0;
-	bgrt_tbl->status &= ~1;
-
-	return 0;
-}
-
 #define acpi_fadt_copy_address(dst, src, len) do {			\
 	if (fadt->header.revision >= FADT2_REVISION_ID &&		\
 	    fadt->header.length >= ACPI_FADT_V2_SIZE)			\
@@ -752,7 +731,5 @@ int __init acpi_boot_init(void)

 	acpi_hest_init();

-	acpi_table_parse(ACPI_SIG_BGRT, acpi_invalidate_bgrt);
-
 	return 0;
 }
--
2.53.0

On Fri, Mar 06, 2026 at 12:48:09AM +0530, Soumyajyotii Ssarkar wrote:
> Now that BGRT images are preserved during EFI boot (via
> EfiACPIReclaimMemory allocation), the invalidation code in
> acpi_parse_bgrt() is no longer needed. The BGRT table remains
> valid throughout boot.
> 
> This removes the code that was marking BGRT invalid when the
> image memory was detected as unavailable, which was causing
> ACPI warnings in Linux dom0.

When preserving failed for any reason, or when it was disabled (the next
patch), the entry still should be invalidated. In fact, the check here
for RAM_TYPE_CONVENTIONAL may already disable invalidation when it got
preserved?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

On Fri, Mar 6, 2026 at 7:23 AM Marek Marczykowski-Górecki <
marmarek@invisiblethingslab.com> wrote:

> On Fri, Mar 06, 2026 at 12:48:09AM +0530, Soumyajyotii Ssarkar wrote:
> > Now that BGRT images are preserved during EFI boot (via
> > EfiACPIReclaimMemory allocation), the invalidation code in
> > acpi_parse_bgrt() is no longer needed. The BGRT table remains
> > valid throughout boot.
> >
> > This removes the code that was marking BGRT invalid when the
> > image memory was detected as unavailable, which was causing
> > ACPI warnings in Linux dom0.
>
> When preserving failed for any reason, or when it was disabled (the next
> patch), the entry still should be invalidated. In fact, the check here
> for RAM_TYPE_CONVENTIONAL may already disable invalidation when it got
> preserved?
>
> --
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
>


I could move forward with dropping the [PATCH 2/3]. And adapt the other
patches accordingly.
This would serve as a safety net in case the preservation fails for any
reason. Would that be a valid approach?

Thank You,
Soumyajyotii Ssarkar

On Fri, Mar 06, 2026 at 08:59:07AM +0530, Soumyajyotii Ssarkar wrote:
> On Fri, Mar 6, 2026 at 7:23 AM Marek Marczykowski-Górecki <
> marmarek@invisiblethingslab.com> wrote:
> 
> > On Fri, Mar 06, 2026 at 12:48:09AM +0530, Soumyajyotii Ssarkar wrote:
> > > Now that BGRT images are preserved during EFI boot (via
> > > EfiACPIReclaimMemory allocation), the invalidation code in
> > > acpi_parse_bgrt() is no longer needed. The BGRT table remains
> > > valid throughout boot.
> > >
> > > This removes the code that was marking BGRT invalid when the
> > > image memory was detected as unavailable, which was causing
> > > ACPI warnings in Linux dom0.
> >
> > When preserving failed for any reason, or when it was disabled (the next
> > patch), the entry still should be invalidated. In fact, the check here
> > for RAM_TYPE_CONVENTIONAL may already disable invalidation when it got
> > preserved?
> >
> > --
> > Best Regards,
> > Marek Marczykowski-Górecki
> > Invisible Things Lab
> >
> 
> 
> I could move forward with dropping the [PATCH 2/3]. And adapt the other
> patches accordingly.
> This would serve as a safety net in case the preservation fails for any
> reason. Would that be a valid approach?

Yes, exactly.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab