Re: [Xen-devel] [PATCH 3/4] x86/boot: Create the l2_xenmap[] mappings dynamically

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.01.2020 18:50, Andrew Cooper wrote:
> The build-time construction of l2_xenmap[] imposes an arbitrary limit of 16M
> total, which is a limit looking to be lifted.
> 
> Move l2_xenmap[] into the bss, and adjust both the BIOS and EFI paths to fill
> it in dynamically, based on the final linked size of Xen.  For current builds,
> this reduces the number of .text/etc mappings from 7 to 4.

Is the 4 named here applicable the same to xen.gz and xen.efi, despite
the latter using large pages with distinct permissions while the former
still doesn't?

> In principle, the non-EFI case could be made to work by having a post-link
> script fill in a suitable number of _PAGE_PRESENT entries in l2_xenmap[].
> This doesn't work for the EFI case, because pagetable relocation is instead
> triggered on the ad-hoc relocation table, which would require the
> _PAGE_PRESENT references to be in place before the link takes place.

And to be honest, such a post-link script would seem rather ugly
to have to me.

> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -668,6 +668,20 @@ trampoline_setup:
>          add     %esi,sym_fs(__page_tables_start)-8(,%ecx,8)
>  2:      loop    1b
>  
> +        /* Map Xen into the higher mappings using 2M superpages. */
> +        lea     _PAGE_PSE + PAGE_HYPERVISOR_RWX + sym_esi(_start), %eax
> +        mov     $sym_offs(_start),   %ecx   /* %eax = PTE to write        */

The comment is on the wrong line, isn't it? Perhaps

        lea     _PAGE_PSE + PAGE_HYPERVISOR_RWX + sym_esi(_start), \
                %eax                /* %eax = PTE to write        */

?

> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -585,6 +585,20 @@ static void __init efi_arch_memory_setup(void)
>      if ( !efi_enabled(EFI_LOADER) )
>          return;
>  
> +    /*
> +     * Map Xen into the higher mappings, using 2M superpages.
> +     *
> +     * NB: We are currently in physical mode, so a RIP-relative relocation
> +     * against _start/_end gets their position as placed by the bootloader,
> +     * not as expected in the final build.  This has arbitrary 2M alignment,
> +     * so subtract xen_phys_start to get the appropriate slots in 
> l2_xenmap[].
> +     */

It may just be a language issue, but I'm struggling with the
"arbitrary" here. Is this in any way related to the
--section-alignment=0x200000 option we pass to the linker (where
the value isn't arbitrary at all)?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel