Re: [RFC PATCH v3 0/3] Fixing ACPI BGRT (Boot Graphics Resource Table) corruption

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Mar 12, 2026 at 04:44:11PM +0530, Soumyajyotii Ssarkar wrote:
> This RFC series plans to addres ACPI BGRT (Boot Graphics Resource Table) 
> corruption,
> that occured when Xen reuses the memory containing the boot logo
> image before dom0 is able to parse ACPI tables.
> 
> The BGRT table contains a pointer to a BMP image stored in
> BootServicesData memory. When Xen reclaims this memory early in boot,
> the pointer becomes invalid, causing Linux dom0 to report:
> Xen: `(XEN) ACPI: BGRT: invalidating v1 image at 0x47cc2018`
> Linux (dom0): `ACPI BIOS Warning (bug): Incorrect checksum
> in table [BGRT] - 0xF9, should be 0xB4 (20250807/utcksum-58)`
> 
> This series:
> 1. Adds BGRT image preservation infrastructure during EFI boot
> (validates BMP format, allocates EfiACPIReclaimMemory, stores pointers)
> 
> 2. Integrates preservation with ACPI subsystem
> (clarifies acpi_invalidate_bgrt() safety net behavior,
> adds status reporting via efi_bgrt_status_info())
> 
> 3. Provides opt-out mechanism
> (-nobgrt for xen.efi direct boot, efi=no-bgrt
> for multiboot2, both via early EFI-phase parsing)
> 
> The preservation is enabled by default to fix the corruption for all
> users, with minimal overhead (~1MB). Also, servers that don't need boot
> graphics can disable it using the "efi=no-bgrt" option.
> 
> Thank you everyone for the constructive feedback! It is really helpful,
> I hope this RFC series is upto standards, I would greatly appriciate further 
> feedback.
> 
> Changes since v1:
> - The BGRT invalidation behaviour should still presist
>   and server as a safety net when "efi=no-bgrt" or the
>   preservation fails for some reason thus: Add Clarify comment
>   for BGRT invalidation behavior with preservation.
> Reported-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> 
> Changes since v2:
> - Use existing ACPI headers (actbl.h, actbl3.h) instead of custom structs
> - Modify the function names and code in function to conform with Coding Style.
> - Reuse efi.acpi20 from efi_tables() instead of manual RSDP search
> - Use appropriate types: EFI types for firmware code, unsigned int for
>   loop counters (matching ESRT pattern)
> - Used of sizeof(<expression>) over sizeof(<type>)
> - Remove fixed-type widths & limited typecasting
> - Add Blank line ahead of the main return statement of a function.
> - Better wording error message for image cap size
> - Remove parse_boolean(no-bgrt) since it could be bit misleading
> - Add const qualifiers throughout for safety
> - Use %p format for pointers (32-bit compatibility)
> - Initialize failure_reason with string literal for proper relocation
> - Use memcmp() with ACPI_SIG_* constants for signature checks
> - Add direct Xen.efi calling.
> - Add opt-out mechanism with proper early parsing during EFI phase.
> 
> Reported-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> Reported-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Please refer to QubesOS Issue for more context:
> https://github.com/QubesOS/qubes-issues/issues/10764
> 
> This is a companion series to Linux Kernel side at
> https://patchew.org/linux/cover.751f45ebbb644244b1d9da3aff289d6b66db4c6b.1773058629.git-series.marmarek@xxxxxxxxxxxxxxxxxxxxxx/
> 
> Testing:
> - Verified on Intel UEFI system with Fedora 43 dom0
> - Before: ACPI checksum errors in dom0
> - After: Clean boot, no ACPI warnings
> - Memory overhead: ~972 KB (preserved image size)
> 
> Signed-off-by: Soumyajyotii Ssarkar <soumyajyotisarkar23@xxxxxxxxx>

Hi,

I've pushed this series to CI, and it fails to build in several targets:
https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/2390562809

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

Attachment: signature.asc
Description: PGP signature