From: Jason Andryuk <jason.andryuk@amd.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
xen-devel@lists.xenproject.org,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH v5 1/6] Revert "xen/x86: bzImage parse kernel_alignment"
Date: Wed, 27 Mar 2024 10:49:13 -0400 [thread overview]
Message-ID: <4dda0bc1-2ae0-462e-a8c2-aff74b9bbbf2@amd.com> (raw)
In-Reply-To: <92754a17-fe02-4050-9ca5-5a1ded3483dc@suse.com>
On 2024-03-27 10:19, Jan Beulich wrote:
> On 27.03.2024 15:08, Jason Andryuk wrote:
>> On 2024-03-27 04:59, Roger Pau Monné wrote:
>>> On Wed, Mar 27, 2024 at 08:22:41AM +0100, Jan Beulich wrote:
>>>> On 26.03.2024 22:38, Jason Andryuk wrote:
>>>>> A new ELF note will specify the alignment for a relocatable PVH kernel.
>>>>> ELF notes are suitable for vmlinux and other ELF files, so this
>>>>> Linux-specific bzImage parsing in unnecessary.
>>>>>
>>>>> This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.
>>>>>
>>>>> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
>>>>
>>>> Since you keep re-sending this: In private discussion Roger has indicated
>>>> that, like me, he too would prefer falling back to the ELF data, before
>>>> falling back to the arch default (Roger, please correct me if I got it
>>>> wrong). That would make it necessary that the change you're proposing to
>>>> revert here is actually kept.
>>>
>>> Sorry, was meaning to reply yesterday but Jason is very fast at
>>> sending new version so I'm always one version behind.
>>
>> :)
>>
>> I was hoping to finish this up and get it in...
>>
>>> IMO the order: ELF note, PHDR alignment, arch default should be the
>>> preferred one.
>>>
>>>> Or wait - what you're reverting is taking the alignment out of the
>>>> bzImage header. I don't expect the BSDs to use that protocol; aiui that's
>>>> entirely Linux-specific.
>>>
>>> Yeah, I don't have strong opinions in keeping this, we already do
>>> bzImage parsing, so we might as well attempt to fetch the alignment
>>> from there if correct:
>>>
>>> ELF note, bzImage kernel_alignment, ELF PHDR alignment, arch default
>>
>> I'm not sure how to handle ELF PHDR vs. arch default. ELF PHDR will
>> always be set, AFAIU. Should that always be respected, which means we
>> don't need an arch default?
>
> A value of 0 (and 1) is specifically permitted, to indicate no alignment.
> We may take 0 to mean default, but what you suggest below is another
> plausible approach. Yet another might be to take anything below PAGE_SIZE
> as "use default".
>
>> To include arch default, it would be something like this:
>>
>> if ( parms->phys_align != UNSET_ADDR )
>> align = parms->phys_align;
>> else if ( bz_align )
>> align = bz_align;
>
> Why do you include bz again here? Didn't you previously indicate the
> header field can't be relied upon? Which is also why, finally, I committed
> this revert earlier today.
Roger wanted to consult the bz value? He mentioned it above. Locally,
I haven't synced with staging yet, and I dropped the revert to start
re-working this...
If present, the bzImage header field is valid. But being
bzImage-specific, it isn't useful for other ELF files. Xen will only
move a kernel with the PHSY32_RELOC Note, so it can just specify an
alignment if it needs to.
Personally, I think using the Note's value or a default is fine. It
seems like the PHDR aligment will just be 0x200000 anyway (for x86-64 at
lease), which matches the default. Specifying the PHYS32_RELOC Note,
but relying on a search for the alignment, seems slightly questionable
to me.
Still, it seemed like the path of least resistance is to just implement
the fallback search like Roger requested. Dropping the bzImage, I guess
I'd go with your PAGE_SIZE suggestions for:
if ( parms->phys_align != UNSET_ADDR )
align = parms->phys_align;
else if ( elf->palign > PAGE_SIZE )
align = elf->palign;
else
align = PHYS32_RELOC_ALIGN_DEFAULT;
Thanks for your reviews.
Regards,
Jason
next prev parent reply other threads:[~2024-03-27 14:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-26 21:38 [PATCH v5 0/6] x86/pvh: Support relocating dom0 kernel Jason Andryuk
2024-03-26 21:38 ` [PATCH v5 1/6] Revert "xen/x86: bzImage parse kernel_alignment" Jason Andryuk
2024-03-27 7:22 ` Jan Beulich
2024-03-27 8:59 ` Roger Pau Monné
2024-03-27 14:08 ` Jason Andryuk
2024-03-27 14:19 ` Jan Beulich
2024-03-27 14:49 ` Jason Andryuk [this message]
2024-03-26 21:38 ` [PATCH v5 2/6] tools/init-xenstore-domain: Replace variable MB() usage Jason Andryuk
2024-03-26 21:38 ` [PATCH v5 3/6] tools: Move MB/GB() to common-macros.h Jason Andryuk
2024-03-26 21:38 ` [PATCH v5 4/6] libelf: Expand ELF note printing Jason Andryuk
2024-03-27 7:27 ` Jan Beulich
2024-03-26 21:38 ` [PATCH v5 5/6] xen/elfnote: Specify ELF Notes are x86-specific Jason Andryuk
2024-03-27 7:24 ` Jan Beulich
2024-03-26 21:38 ` [PATCH v5 6/6] x86/PVH: Support relocatable dom0 kernels Jason Andryuk
2024-03-26 21:47 ` [PATCH v5] RFC: x86/pvh: Make Xen PVH entrypoint PIC for x86-64 Jason Andryuk
2024-03-27 8:20 ` Jan Beulich
2024-03-27 14:15 ` Jason Andryuk
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=4dda0bc1-2ae0-462e-a8c2-aff74b9bbbf2@amd.com \
--to=jason.andryuk@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@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.