All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Soumyajyotii Ssarkar" <soumyajyotisarkar23@gmail.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Daniel P . Smith" <dpsmith@apertussolutions.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	sarkarsoumyajyoti23@gmail.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 2/3] x86/acpi: Integrate BGRT preservation with status reporting
Date: Wed, 25 Mar 2026 16:32:29 +0100	[thread overview]
Message-ID: <acQADhcNzkVBm3C3@mail-itl> (raw)
In-Reply-To: <751e1d3e-d95a-4129-8baa-450a53d15efa@suse.com>

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

On Wed, Mar 25, 2026 at 04:16:25PM +0100, Jan Beulich wrote:
> On 24.03.2026 13:33, Soumyajyotii Ssarkar wrote:
> > @@ -327,6 +328,11 @@ static int __init cf_check acpi_parse_hpet(struct acpi_table_header *table)
> >  	return 0;
> >  }
> > 
> > +/*
> > + * Invalidate BGRT if image is in conventional RAM (preservation failed).
> > + * If preservation succeeded, image is in EfiACPIReclaimMemory, which
> > + * won't match RAM_TYPE_CONVENTIONAL check, so table remains valid.
> > + */
> >  static int __init cf_check acpi_invalidate_bgrt(struct acpi_table_header *table)
> >  {
> >  	struct acpi_table_bgrt *bgrt_tbl =
> > @@ -754,5 +760,7 @@ int __init acpi_boot_init(void)
> > 
> >  	acpi_table_parse(ACPI_SIG_BGRT, acpi_invalidate_bgrt);
> > 
> > +	efi_bgrt_status_info();
> > +
> >  	return 0;
> >  }
> 
> Does this really need doing from here? If you called it ...
> 
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -1911,6 +1911,22 @@ static bool __init cf_check rt_range_valid(unsigned long smfn, unsigned long emf
> >      return true;
> >  }
> > 
> > +void __init efi_bgrt_status_info(void)
> > +{
> > +    if ( !efi_enabled(EFI_BOOT) )
> > +        return;
> > +
> > +    if ( bgrt_info.preserved )
> > +    {
> > +        printk(XENLOG_INFO "EFI: BGRT image preserved: %lu KB\n",
> > +               bgrt_info.size / 1024);
> > +        printk(XENLOG_INFO "EFI: BGRT relocated from %p to %p\n",
> > +               bgrt_info.old_addr, bgrt_info.new_addr);
> > +    }
> > +    else if ( bgrt_info.failure_reason[0] )
> > +        printk(XENLOG_WARNING "EFI: BGRT preservation failed: %s\n",
> > +               bgrt_info.failure_reason);
> > +}
> > 
> >  void __init efi_init_memory(void)
> >  {
> 
> ... out of this function, it could be static and no stub (misplaced in
> the earlier patch) would be needed either.

It was here before, and I complained about it, because it printed the
invalidation reason way later than the actual invalidation.

> Furthermore, is the EFI_BOOT check really needed? Without taking either
> of the EFI boot paths, neither bgrt_info.preserved nor
> bgrt_info.failure_reason[0] would have been altered from their initial
> values.
> 
> Jan

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2026-03-25 15:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 12:33 [PATCH v5 0/3] Fixing ACPI BGRT (Boot Graphics Resource Table) corruption Soumyajyotii Ssarkar
2026-03-24 12:33 ` [PATCH v5 1/3] x86/efi: Add BGRT image preservation infrastructure Soumyajyotii Ssarkar
2026-03-24 17:05   ` Jan Beulich
2026-03-25 15:32   ` Jan Beulich
2026-03-24 12:33 ` [PATCH v5 2/3] x86/acpi: Integrate BGRT preservation with status reporting Soumyajyotii Ssarkar
2026-03-25 15:16   ` Jan Beulich
2026-03-25 15:32     ` Marek Marczykowski-Górecki [this message]
2026-03-25 15:44       ` Jan Beulich
2026-03-25 15:57         ` Marek Marczykowski-Górecki
2026-03-26  8:45           ` Jan Beulich
2026-03-26 10:00             ` Marek Marczykowski-Górecki
2026-03-24 12:33 ` [PATCH v5 3/3] x86/efi: Add opt-out mechanism for BGRT preservation Soumyajyotii Ssarkar
2026-03-25 15:31   ` 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=acQADhcNzkVBm3C3@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=sarkarsoumyajyoti23@gmail.com \
    --cc=soumyajyotisarkar23@gmail.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.