[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/3] x86/boot: Refactor BIOS/PVH start



On 10.09.2024 18:16, Frediano Ziglio wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -25,6 +25,9 @@
>  #define MB2_HT(name)      (MULTIBOOT2_HEADER_TAG_##name)
>  #define MB2_TT(name)      (MULTIBOOT2_TAG_TYPE_##name)
>  
> +#define BOOT_TYPE_BIOS 1
> +#define BOOT_TYPE_PVH 2

Did you consider using 0 and 1, to be able to use XOR on the BIOS
path and TEST for checking?

> @@ -409,13 +412,28 @@ cs32_switch:
>  ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, .long sym_offs(__pvh_start))
>  
>  __pvh_start:
> -        cld
>          cli
> +        mov     $BOOT_TYPE_PVH, %ebp
> +        jmp     common_bios_pvh
> +#endif /* CONFIG_PVH_GUEST */
> +
> +__start:
> +        cli
> +        mov     $BOOT_TYPE_BIOS, %ebp
> +
> +common_bios_pvh:

I think labels like this one don't need to show up in the symbol
table, and hence would better start with .L.

> +        cld

So you fold the STDs but not the STIs, despite that not even having
been first on the PVH path. This decision wants explaining in the
description, even if just briefly.

> @@ -433,14 +451,9 @@ __pvh_start:
>          /* Set up stack. */
>          lea     STACK_SIZE - CPUINFO_sizeof + sym_esi(cpu0_stack), %esp
>  
> -        call    initialise_bss

I'm little puzzled: The previous patch moved it "as early as possible"
just for it to be moved to a later point again here?

> -        mov     %ebx, sym_esi(pvh_start_info_pa)
> -
> -        /* Force xen console.  Will revert to user choice in init code. */
> -        movb    $-1, sym_esi(opt_console_xen)
> -
> -        /* Prepare gdt and segments */
> +        /*
> +         * Initialize GDTR and basic data segments.
> +         */
>          add     %esi, sym_esi(gdt_boot_base)
>          lgdt    sym_esi(gdt_boot_descr)

No real need to change the comment? In any even it wants to remain a
single-line one.

> @@ -449,67 +462,44 @@ __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 descriptor to unused segment registers. */
> +        xor     %ecx, %ecx
> +        mov     %ecx, %fs
> +        mov     %ecx, %gs

The comment said "descriptor", yes, but it's a null selector that
we load here. Perhaps worth adjusting as the comment is moved.

> -initialise_bss:
>          /*
>           * Initialise the BSS.
>           *
>           * !!! WARNING - also zeroes the current stack !!!
>           */
> -        pop     %ebp
>          mov     %eax, %edx
> -
>          lea     sym_esi(__bss_start), %edi
>          lea     sym_esi(__bss_end), %ecx
>          sub     %edi, %ecx
>          xor     %eax, %eax
>          shr     $2, %ecx
>          rep stosl
> -
>          mov     %edx, %eax
> -        jmp     *%ebp
> -
> -__start:
> -        cld
> -        cli
>  
> -        /*
> -         * Multiboot (both 1 and 2) specify the stack pointer as undefined
> -         * when entering in BIOS circumstances.  This is unhelpful for
> -         * relocatable images, where one call (i.e. push) is required to
> -         * calculate the image's load address.
> -         *
> -         * This early in 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.
> -         */
> -
> -        /* Preserve the field we're about to clobber. */
> -        mov     (%ebx), %edx
> -        lea     4(%ebx), %esp
> +#ifdef CONFIG_PVH_GUEST
> +        cmp     $BOOT_TYPE_PVH, %ebp
> +        jne     1f
>  
> -        /* Calculate the load base address. */
> -        call    1f
> -1:      pop     %esi
> -        sub     $sym_offs(1b), %esi
> +        mov     %ebx, sym_esi(pvh_start_info_pa)
>  
> -        /* Restore the clobbered field. */
> -        mov     %edx, (%ebx)
> +        /* Force xen console.  Will revert to user choice in init code. */
> +        movb    $-1, sym_esi(opt_console_xen)
>  
> -        /* Set up stack. */
> -        lea     STACK_SIZE - CPUINFO_sizeof + sym_esi(cpu0_stack), %esp
> +        /* Skip bootloader setup and bios setup, go straight to trampoline */
> +        movb    $1, sym_esi(pvh_boot)
> +        movb    $1, sym_esi(skip_realmode)
>  
> -        call    initialise_bss
> +        /* Set trampoline_phys to use mfn 1 to avoid having a mapping at VA 
> 0 */
> +        movw    $0x1000, sym_esi(trampoline_phys)

I realize you merely move this, yet I question the use of MOVW here.
You use 32-bit operations e.g. to set %ebp; perhaps the same should
be done here, even if that means a 1 byte code size increase. In any
even this would preferably use PAGE_SIZE imo.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.