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

Re: [RFC v2 02/12] xen/arm32: head: Jump to the runtime mapping in enable_mmu()


  • To: Julien Grall <julien@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Tue, 25 Oct 2022 11:45:16 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XVJ24SY2srO3UWkRsdbW+YFox9PstZGdzk6L5FJN7pM=; b=ALfRYMlLpSJ6h+96+CXcOdUNIe2tiJBA3CM89dfIxhp2R0i0YfXMHRXg99aOBXo45SHoKVQngjpGF3/etQP59fRw5kwPS7VEo+3b771481m8BVi+iUqZHikT+edCvjUBNo8kiQPPGvWyq7yCn6AE+HensVz2/sZ2CBbz9C3o+c1Zw7jFGGIFrB0j/cFey32CxgZsV4ozF64nGtWexX1iU9kluX/BX+74EUoCfS417vhHdIM6+okH5UXfndb5fLe4DgUF+MhXnWjTBGm150BVnI5cxY/bpOg5dkLbhhPzWHKVvbFPXTnQg8/+NKp/AL1ISM77r0/JmsVtjZUYRz+Tmw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OuY/Szn4wbvP2sMUowucqeBm4McML0r7v9a+kOh8HQh7WxG/MClEBo8SI2QgxMjHHfnXlITcyp36jsfpRXrj8Z4bj/tY6UIfhsdYyDmLmNrNPk45ouYx0sSV20qmgRKs0fXvwALRWItnHzW+QIhhsahJGq0GT78CtZbH+KlUCx/7EUe2+oZty7dohp3oBOQJgZL2Td7CpE11lTdKoj49+Zv4TG46js/z2v+hwGwBZiLXKd6A1/eqr83DNMlaOXsa+TxSZ4RS9D4bq+ka4zwQQxbdvRogu7pr2YvYCsIveqcGNsP7vN37wtPR2ZJLJFWZZuUbjZMvGIDnqT8hZbqdLA==
  • Cc: <marco.solieri@xxxxxxxxxxxxxxx>, <lucmiccio@xxxxxxxxx>, <carlo.nonato@xxxxxxxxxxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>, "Stefano Stabellini" <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Tue, 25 Oct 2022 09:45:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Julien,

On 22/10/2022 17:04, Julien Grall wrote:
> 
> 
> From: Julien Grall <jgrall@xxxxxxxxxx>
> 
> At the moment, enable_mmu() will return to an address in the 1:1 mapping
> and each path are responsible to switch to the runtime mapping.
s/are/is/

> 
> In a follow-up patch, the behavior to switch to the runtime mapping
> will become more complex. So to avoid more code/comment duplication,
> move the switch in enable_mmu().
> 
> Lastly, take the opportunity to replace load from literal pool with
> mov_w.
> 
> Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx>
> ---
>  xen/arch/arm/arm32/head.S | 51 ++++++++++++++++++++++++---------------
>  1 file changed, 31 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
> index a558c2a6876e..163bd6596dec 100644
> --- a/xen/arch/arm/arm32/head.S
> +++ b/xen/arch/arm/arm32/head.S
> @@ -167,19 +167,12 @@ past_zImage:
>          bl    check_cpu_mode
>          bl    cpu_init
>          bl    create_page_tables
> -        bl    enable_mmu
> 
> -        /* We are still in the 1:1 mapping. Jump to the runtime Virtual 
> Address. */
> -        ldr   r0, =primary_switched
> -        mov   pc, r0
> +        /* Address in the runtime mapping to jump to after the MMU is 
> enabled */
> +        mov_w lr, primary_switched
We seem to still widely use ldr instead of mov_w which is faster.
It looks like a prerequisite patch to convert all occurences or something to 
keep in a backlog.

> +        b     enable_mmu
> +
>  primary_switched:
> -        /*
> -         * The 1:1 map may clash with other parts of the Xen virtual memory
> -         * layout. As it is not used anymore, remove it completely to
> -         * avoid having to worry about replacing existing mapping
> -         * afterwards.
> -         */
> -        bl    remove_identity_mapping
>          bl    setup_fixmap
>  #ifdef CONFIG_EARLY_PRINTK
>          /* Use a virtual address to access the UART. */
> @@ -223,12 +216,10 @@ GLOBAL(init_secondary)
>          bl    check_cpu_mode
>          bl    cpu_init
>          bl    create_page_tables
> -        bl    enable_mmu
> -
> 
> -        /* We are still in the 1:1 mapping. Jump to the runtime Virtual 
> Address. */
> -        ldr   r0, =secondary_switched
> -        mov   pc, r0
> +        /* Address in the runtime mapping to jump to after the MMU is 
> enabled */
> +        mov_w lr, secondary_switched
> +        b     enable_mmu
>  secondary_switched:
>          /*
>           * Non-boot CPUs need to move on to the proper pagetables, which were
> @@ -523,9 +514,12 @@ virtphys_clash:
>  ENDPROC(create_page_tables)
> 
>  /*
> - * Turn on the Data Cache and the MMU. The function will return on the 1:1
> - * mapping. In other word, the caller is responsible to switch to the runtime
> - * mapping.
> + * Turn on the Data Cache and the MMU. The function will return
> + * to the virtual address provided in LR (e.g. the runtime mapping).
> + *
> + * Inputs:
> + *   r9 : paddr(start)
> + *   lr : Virtual address to return to
>   *
>   * Clobbers r0 - r3
>   */
> @@ -551,7 +545,24 @@ enable_mmu:
>          dsb                          /* Flush PTE writes and finish reads */
>          mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
>          isb                          /* Now, flush the icache */
> -        mov   pc, lr
> +
> +        /*
> +         * The MMU is turned on and we are in the 1:1 mapping. Switch
> +         * to the runtime mapping.
> +         */
> +        mov_w r0, 1f
> +        mov   pc, r0
Would it be possible to stop using:
        mov pc, reg
in favor of using:
        bx reg

Some time ago I saw this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/include/asm/assembler.h?id=6ebbf2ce437b33022d30badd49dc94d33ecfa498
which states that bx is faster.

> +1:
> +        /*
> +         * The 1:1 map may clash with other parts of the Xen virtual memory
> +         * layout. As it is not used anymore, remove it completely to
> +         * avoid having to worry about replacing existing mapping
> +         * afterwards.
> +         *
> +         * On return this will jump to the virtual address requested by
> +         * the caller.
> +         */
> +        b     remove_identity_mapping
>  ENDPROC(enable_mmu)
> 
>  /*
> --
> 2.37.1
> 
> 

Apart from that, the change looks ok.

~Michal



 


Rackspace

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