| Message ID | 20210520123012.89855-2-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | libelf: small fixes for PVH | expand |
On 20.05.2021 14:30, Roger Pau Monne wrote: > The legacy __xen_guest section doesn't support the PHYS32_ENTRY > elfnote, so it's pointless to attempt to parse the elfnotes from that > section when called from an hvm container. > > Suggested-by: Jan Beulich <jbeulich@suse.com> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > --- > Changes since v2: > - New in this version. > --- > xen/common/libelf/libelf-dominfo.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c > index 69c94b6f3bb..abea1011c18 100644 > --- a/xen/common/libelf/libelf-dominfo.c > +++ b/xen/common/libelf/libelf-dominfo.c > @@ -577,10 +577,8 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf, > > } > > - /* > - * Finally fall back to the __xen_guest section. > - */ > - if ( xen_elfnotes == 0 ) > + /* Finally fall back to the __xen_guest section for PV guests only. */ > + if ( xen_elfnotes == 0 && !hvm ) Isn't this depending on the 2nd patch adding the function parameter? IOW doesn't this break the build, even if just transiently? With the respective hunk from patch 2 moved here Reviewed-by: Jan Beulich <jbeulich@suse.com> Jan
On 20.05.2021 14:35, Jan Beulich wrote: > On 20.05.2021 14:30, Roger Pau Monne wrote: >> The legacy __xen_guest section doesn't support the PHYS32_ENTRY >> elfnote, so it's pointless to attempt to parse the elfnotes from that >> section when called from an hvm container. >> >> Suggested-by: Jan Beulich <jbeulich@suse.com> >> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> >> --- >> Changes since v2: >> - New in this version. >> --- >> xen/common/libelf/libelf-dominfo.c | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c >> index 69c94b6f3bb..abea1011c18 100644 >> --- a/xen/common/libelf/libelf-dominfo.c >> +++ b/xen/common/libelf/libelf-dominfo.c >> @@ -577,10 +577,8 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf, >> >> } >> >> - /* >> - * Finally fall back to the __xen_guest section. >> - */ >> - if ( xen_elfnotes == 0 ) >> + /* Finally fall back to the __xen_guest section for PV guests only. */ >> + if ( xen_elfnotes == 0 && !hvm ) > > Isn't this depending on the 2nd patch adding the function parameter? > IOW doesn't this break the build, even if just transiently? With the > respective hunk from patch 2 moved here > Reviewed-by: Jan Beulich <jbeulich@suse.com> With the intention of committing I did this hunk movement, noticing that - it's more than just one hunk, - a tool stack maintainer ack is actually going to be needed (all respective hunks are now in the first patch). I'll keep the massaged patches locally, until the missing ack arrives. Jan
On 21.05.2021 15:31, Jan Beulich wrote: > On 20.05.2021 14:35, Jan Beulich wrote: >> On 20.05.2021 14:30, Roger Pau Monne wrote: >>> The legacy __xen_guest section doesn't support the PHYS32_ENTRY >>> elfnote, so it's pointless to attempt to parse the elfnotes from that >>> section when called from an hvm container. >>> >>> Suggested-by: Jan Beulich <jbeulich@suse.com> >>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> >>> --- >>> Changes since v2: >>> - New in this version. >>> --- >>> xen/common/libelf/libelf-dominfo.c | 6 ++---- >>> 1 file changed, 2 insertions(+), 4 deletions(-) >>> >>> diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c >>> index 69c94b6f3bb..abea1011c18 100644 >>> --- a/xen/common/libelf/libelf-dominfo.c >>> +++ b/xen/common/libelf/libelf-dominfo.c >>> @@ -577,10 +577,8 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf, >>> >>> } >>> >>> - /* >>> - * Finally fall back to the __xen_guest section. >>> - */ >>> - if ( xen_elfnotes == 0 ) >>> + /* Finally fall back to the __xen_guest section for PV guests only. */ >>> + if ( xen_elfnotes == 0 && !hvm ) >> >> Isn't this depending on the 2nd patch adding the function parameter? >> IOW doesn't this break the build, even if just transiently? With the >> respective hunk from patch 2 moved here >> Reviewed-by: Jan Beulich <jbeulich@suse.com> > > With the intention of committing I did this hunk movement, noticing > that > - it's more than just one hunk, > - a tool stack maintainer ack is actually going to be needed (all > respective hunks are now in the first patch). > I'll keep the massaged patches locally, until the missing ack arrives. I've timed out waiting for an ack and committed the patches, considering the tool stack parts of them are mechanical enough. Jan
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c index 69c94b6f3bb..abea1011c18 100644 --- a/xen/common/libelf/libelf-dominfo.c +++ b/xen/common/libelf/libelf-dominfo.c @@ -577,10 +577,8 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf, } - /* - * Finally fall back to the __xen_guest section. - */ - if ( xen_elfnotes == 0 ) + /* Finally fall back to the __xen_guest section for PV guests only. */ + if ( xen_elfnotes == 0 && !hvm ) { shdr = elf_shdr_by_name(elf, "__xen_guest"); if ( ELF_HANDLE_VALID(shdr) )
The legacy __xen_guest section doesn't support the PHYS32_ENTRY elfnote, so it's pointless to attempt to parse the elfnotes from that section when called from an hvm container. Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Changes since v2: - New in this version. --- xen/common/libelf/libelf-dominfo.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)