All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Frediano Ziglio <frediano.ziglio@cloud.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	"Ross Lagerwall" <ross.lagerwall@citrix.com>,
	"Jan Beulich" <JBeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Daniel P . Smith" <dpsmith@apertussolutions.com>
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
Date: Tue, 29 Jul 2025 18:17:11 +0200	[thread overview]
Message-ID: <aIj0BzGAH0G5ypbD@mail-itl> (raw)
In-Reply-To: <CACHz=Zhkt-a+vTPg+HJhSU=qvir94hiZOKjoBoZofeGpac+sGQ@mail.gmail.com>

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

On Fri, Jun 27, 2025 at 02:08:00PM +0100, Frediano Ziglio wrote:
> On Thu, Jun 5, 2025 at 12:17 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >
> > The format of the buildid is a property of the binary, not a property of how
> > it was loaded.  This fixes buildid recognition when starting xen.efi from it's
> > MB2 entrypoint.
> >
> > Suggested-by: Ross Lagerwall <ross.lagerwall@citrix.com>
> > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > ---
> > CC: Jan Beulich <JBeulich@suse.com>
> > CC: Roger Pau Monné <roger.pau@citrix.com>
> > CC: Ross Lagerwall <ross.lagerwall@citrix.com>
> > CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> > CC: Daniel P. Smith <dpsmith@apertussolutions.com>
> >
> > I don't like this patch and tried hard to do it in a better way, but the EFI
> > aspects of the build system are too intractable.
> >
> > While on x86 I can in principle pull the same common-stubs.o trick, split on
> > XEN_BUILD_PE rather than XEN_BUILD_EFI, that doesn't work on ARM which
> > hand-codes it's PE-ness.  Also, it's really not EFI related, other than as a
> > consequence of that being the only reason we use PE32+ binaries.

Besides the ARM issue, it would also make it harder to follow different
boot paths.

> >
> > Binutils 2.25 is now the minimum, and the makefiles can be cleaned up
> > somewhat, but I need to backport this patch, internally at least.
> > ---
> >  xen/common/version.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/common/version.c b/xen/common/version.c
> > index 5474b8e385be..56b51c81d2fc 100644
> > --- a/xen/common/version.c
> > +++ b/xen/common/version.c
> > @@ -203,8 +203,11 @@ void __init xen_build_init(void)
> >      rc = xen_build_id_check(n, sz, &build_id_p, &build_id_len);
> >
> >  #ifdef CONFIG_X86
> > -    /* Alternatively we may have a CodeView record from an EFI build. */
> > -    if ( rc && efi_enabled(EFI_LOADER) )
> > +    /*
> > +     * xen.efi built with a new enough toolchain will have a CodeView record,
> > +     * not an ELF note.
> > +     */
> > +    if ( rc )
> >      {
> >          const struct pe_external_debug_directory *dir = (const void *)n;
> >
> 
> Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> 
> I cannot see a better proposal in the discussion, but I prefer this
> fixed than keep it broken.

Yeah, I agree.

Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

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

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

  reply	other threads:[~2025-07-29 16:17 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-05 11:16 [PATCH 0/3] x86/EFI: Fix detection of buildid Andrew Cooper
2025-06-05 11:16 ` [PATCH 1/3] " Andrew Cooper
2025-06-05 12:02   ` Jan Beulich
2025-06-05 12:14     ` Andrew Cooper
2025-06-05 13:24       ` Jan Beulich
2025-06-05 17:01         ` Andrew Cooper
2025-06-06  7:22           ` Jan Beulich
2025-06-06  7:23             ` Jan Beulich
2025-06-06 15:01             ` Andrew Cooper
2025-06-10  8:01               ` Jan Beulich
2025-06-13 21:28                 ` Andrew Cooper
2025-06-16  6:27                   ` Jan Beulich
2025-06-23 20:18                     ` Andrew Cooper
2025-06-24  8:01                       ` Jan Beulich
2025-06-13 21:31             ` Stefano Stabellini
2025-06-05 12:20     ` Marek Marczykowski-Górecki
2025-06-05 13:08       ` Jan Beulich
2025-06-05 13:34         ` Marek Marczykowski-Górecki
2025-06-27 13:08   ` Frediano Ziglio
2025-07-29 16:17     ` Marek Marczykowski-Górecki [this message]
2025-06-30 10:50   ` Roger Pau Monné
2025-07-29 16:16   ` Daniel Smith
2025-06-05 11:16 ` [PATCH 2/3] x86/EFI: Explain buildid.ihex Andrew Cooper
2025-06-05 12:03   ` Jan Beulich
2025-07-29 16:18   ` Marek Marczykowski-Górecki
2025-06-05 11:16 ` [PATCH 3/3] xen/EFI: Drop __ASSEMBLY__ ifdefary in efi.h Andrew Cooper
2025-06-05 12:05   ` Jan Beulich
2025-07-29 16:19   ` Marek Marczykowski-Górecki
2025-07-29 16:24   ` Daniel Smith

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=aIj0BzGAH0G5ypbD@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=frediano.ziglio@cloud.com \
    --cc=roger.pau@citrix.com \
    --cc=ross.lagerwall@citrix.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.