From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Frediano Ziglio <frediano.ziglio@cloud.com>,
xen-devel@lists.xenproject.org
Cc: "Jan Beulich" <jbeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH v3 2/4] x86/boot: Refactor BIOS/PVH start
Date: Tue, 24 Sep 2024 14:30:52 +0100 [thread overview]
Message-ID: <bb00d412-9b79-490b-b028-e4867a025c91@citrix.com> (raw)
In-Reply-To: <91bf7854-83e8-42cc-a28b-21aaa472bb1f@citrix.com>
On 24/09/2024 2:25 pm, Andrew Cooper wrote:
> On 24/09/2024 11:28 am, Frediano Ziglio wrote:
>> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
>> index fa21024042..80bba6ff21 100644
>> --- a/xen/arch/x86/boot/head.S
>> +++ b/xen/arch/x86/boot/head.S
>> ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, .long sym_offs(__pvh_start))
>>
>> __pvh_start:
>> - cld
>> + mov $BOOT_TYPE_PVH, %dl
>> + jmp .Lcommon_bios_pvh
>> +#endif /* CONFIG_PVH_GUEST */
>> +
>> +__start:
>> + mov $BOOT_TYPE_BIOS, %dl
> Even if we're generally using %dl, these must be full %edx writes.
>
> %edx commonly contains FMS on entry, and we don't want part of FMS left
> in the upper half of the register.
>
>> +
>> +.Lcommon_bios_pvh:
>> cli
>> + cld
>>
>> /*
>> - * We need one call (i.e. push) to determine the load address. See
>> - * __start for a discussion on how to do this safely using the PVH
>> - * info structure.
>> + * Multiboot (both 1 and 2) and PVH specify the stack pointer as
>> + * undefined. This is unhelpful for relocatable images, where one
>> + * call (i.e. push) is required to calculate the image's load address.
>> + *
>> + * Durig BIOS boot, there is one area of memory we know about with
>> + * reasonable confidence that it isn't overlapped by Xen, and that's
>> + * the Multiboot info structure in %ebx. Use it as a temporary stack.
>> + *
>> + * During PVH boot use info structure in %ebx.
>> */
>>
>> /* Preserve the field we're about to clobber. */
>> - mov (%ebx), %edx
>> + mov (%ebx), %ecx
> Both here, and ...
>
>> lea 4(%ebx), %esp
>>
>> /* Calculate the load base address. */
>> @@ -449,62 +459,40 @@ __pvh_start:
>> mov %ecx, %es
>> mov %ecx, %ss
>>
>> - /* Skip bootloader setup and bios setup, go straight to trampoline */
>> - movb $1, sym_esi(pvh_boot)
>> - movb $1, sym_esi(skip_realmode)
>> -
>> - /* Set trampoline_phys to use mfn 1 to avoid having a mapping at VA 0 */
>> - movw $0x1000, sym_esi(trampoline_phys)
>> - mov (%ebx), %eax /* mov $XEN_HVM_START_MAGIC_VALUE, %eax */
>> - jmp trampoline_setup
>> -
>> -#endif /* CONFIG_PVH_GUEST */
>> + /* Load null selector to unused segment registers. */
>> + xor %ecx, %ecx
>> + mov %ecx, %fs
>> + mov %ecx, %gs
>>
>> -.Linitialise_bss:
>> /* Initialise the BSS. */
>> - mov %eax, %edx
>> -
>> + mov %eax, %ebp
> ... here, we've got changes caused by now using %edx for a long-lived
> purpose (and a change in linebreaks.)
>
> For this, %ebp should be used straight away in patch 1. I've not
> committed it yet, so can fix that up.
>
>
> I have to admit that I think this patch would be easier if the "use %ebx
> for BOOT_TYPE_*" change was split out of "better merge the BIOS/PVH
> paths". That would at least get the incidental %edx changes out of the way.
>
> Also, inserting
>
> #ifdef CONFIG_PVH_GUEST
> cmp $BOOT_TYPE_PVH, %dl
> jne 1f
> 1:
> #endif /* CONFIG_PVH_GUEST */
>
> in the same patch will probably make the subsequent diff far more legible.
>
> Thoughts?
>
> I might give this a quick go, and see how it ends up looking...
Actually, why do we need BOOT_TYPE_* at all? We've already got
BOOTLOADER_MAGIC in %eax which can be used to identify PVH.
~Andrew
next prev parent reply other threads:[~2024-09-24 13:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-24 10:28 [PATCH v3 0/4] x86/boot: Reduce assembly code Frediano Ziglio
2024-09-24 10:28 ` [PATCH v3 1/4] x86/boot: Initialise BSS sooner Frediano Ziglio
2024-09-24 12:47 ` Andrew Cooper
2024-09-24 10:28 ` [PATCH v3 2/4] x86/boot: Refactor BIOS/PVH start Frediano Ziglio
2024-09-24 13:25 ` Andrew Cooper
2024-09-24 13:30 ` Andrew Cooper [this message]
2024-09-24 13:45 ` Andrew Cooper
2024-09-24 10:28 ` [PATCH v3 3/4] x86/boot: Rewrite EFI/MBI2 code partly in C Frediano Ziglio
2024-09-24 14:08 ` Andrew Cooper
2024-09-24 14:17 ` Jan Beulich
2024-09-24 14:28 ` Frediano Ziglio
2024-09-24 14:42 ` Jan Beulich
2024-09-24 10:28 ` [PATCH v3 4/4] x86/boot: Improve MBI2 structure check Frediano Ziglio
2024-09-24 14:15 ` Andrew Cooper
2024-09-24 14:20 ` Frediano Ziglio
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=bb00d412-9b79-490b-b028-e4867a025c91@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=frediano.ziglio@cloud.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.