All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Cc: julien@xen.org, Julien Grall <jgrall@amazon.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v2 1/2] xen/arm32: head: Rework how the fixmap and early UART mapping are prepared
Date: Thu, 11 Jan 2024 18:34:09 +0000	[thread overview]
Message-ID: <20240111183410.45566-2-julien@xen.org> (raw)
In-Reply-To: <20240111183410.45566-1-julien@xen.org>

From: Julien Grall <jgrall@amazon.com>

Since commit 5e213f0f4d2c ("xen/arm32: head: Widen the use of the
temporary mapping"), boot_second (used to cover regions like Xen and
the fixmap) will not be mapped if the identity mapping overlap.

So it is ok to prepare the fixmap table and link it in boot_second
earlier. With that, the fixmap can also be used earlier via the
temporary mapping.

Therefore split setup_fixmap() in two:
    * The table is now linked in create_page_tables() because
      the boot page tables needs to be recreated for every CPU.
    * The early UART mapping is only added for the boot CPU0 as the
      fixmap table is not cleared when secondary CPUs boot.

Signed-off-by: Julien Grall <jgrall@amazon.com>

----

    Changelog since v1:
        * Rebase
        * Move the UART mapping enable_mm_boot_cpu()
---
 xen/arch/arm/arm32/mmu/head.S | 61 ++++++++---------------------------
 1 file changed, 14 insertions(+), 47 deletions(-)

diff --git a/xen/arch/arm/arm32/mmu/head.S b/xen/arch/arm/arm32/mmu/head.S
index 4e6395e7876d..a90799ad5451 100644
--- a/xen/arch/arm/arm32/mmu/head.S
+++ b/xen/arch/arm/arm32/mmu/head.S
@@ -165,11 +165,6 @@
  * Rebuild the boot pagetable's first-level entries. The structure
  * is described in mm.c.
  *
- * After the CPU enables paging it will add the fixmap mapping
- * to these page tables, however this may clash with the 1:1
- * mapping. So each CPU must rebuild the page tables here with
- * the 1:1 in place.
- *
  * Inputs:
  *   r9 : paddr(start)
  *   r10: phys offset
@@ -197,6 +192,10 @@ create_page_tables:
         add   r5, r5, #PAGE_SIZE            /* r5 := Next table */
 .endr
 
+        /* Map the fixmap into boot_second */
+        mov_w r0, FIXMAP_ADDR(0)
+        create_table_entry boot_second, xen_fixmap, r0, 2
+
         /*
          * Find the size of Xen in pages and multiply by the size of a
          * PTE. This will then be compared in the mapping loop below.
@@ -442,19 +441,20 @@ ENDPROC(enable_secondary_cpu_mm)
 ENTRY(enable_boot_cpu_mm)
         mov   r6, lr
 
+#ifdef CONFIG_EARLY_PRINTK
+        /*
+         * Add the UART mapping to the fixmap so the UART can be used
+         * as the MMU is on. This only need to do done on the boot CPU.
+         */
+        mov_w r0, EARLY_UART_VIRTUAL_ADDRESS
+        create_mapping_entry xen_fixmap, r0, r11, type=PT_DEV_L3
+#endif
+
         bl    create_page_tables
 
         /* Address in the runtime mapping to jump to after the MMU is enabled */
-        mov_w lr, 1f
-        b     enable_mmu
-1:
         mov   lr, r6
-
-        /*
-         * Prepare the fixmap. The function will return to the virtual address
-         * requested by the caller.
-         */
-        b     setup_fixmap
+        b     enable_mmu
 ENDPROC(enable_boot_cpu_mm)
 
 /*
@@ -503,39 +503,6 @@ remove_temporary_mapping:
         mov  pc, lr
 ENDPROC(remove_temporary_mapping)
 
-/*
- * Map the UART in the fixmap (when earlyprintk is used) and hook the
- * fixmap table in the page tables.
- *
- * The fixmap cannot be mapped in create_page_tables because it may
- * clash with the 1:1 mapping.
- *
- * Inputs:
- *   r10: Physical offset
- *   r11: Early UART base physical address
- *
- * Clobbers r0 - r4
- */
-setup_fixmap:
-#if defined(CONFIG_EARLY_PRINTK)
-        /* Add UART to the fixmap table */
-        mov_w r0, EARLY_UART_VIRTUAL_ADDRESS
-        create_mapping_entry xen_fixmap, r0, r11, type=PT_DEV_L3
-#endif
-        /* Map fixmap into boot_second */
-        mov_w r0, FIXMAP_ADDR(0)
-        create_table_entry boot_second, xen_fixmap, r0, 2
-        /* Ensure any page table updates made above have occurred. */
-        dsb   nshst
-        /*
-         * The fixmap area will be used soon after. So ensure no hardware
-         * translation happens before the dsb completes.
-         */
-        isb
-
-        mov   pc, lr
-ENDPROC(setup_fixmap)
-
 /* Fail-stop */
 fail:   PRINT("- Boot failed -\r\n")
 1:      wfe
-- 
2.40.1



  reply	other threads:[~2024-01-11 18:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 18:34 [PATCH v2 0/2] xen/arm32: Improve logging during early boot Julien Grall
2024-01-11 18:34 ` Julien Grall [this message]
2024-01-12  7:46   ` [PATCH v2 1/2] xen/arm32: head: Rework how the fixmap and early UART mapping are prepared Michal Orzel
2024-01-12 10:44     ` Julien Grall
2024-01-11 18:34 ` [PATCH v2 2/2] xen/arm32: head: Improve logging in head.S Julien Grall
2024-01-12  8:49   ` Michal Orzel
2024-01-12 10:58     ` Julien Grall
2024-01-12 11:25       ` Michal Orzel
2024-01-12 11:55         ` Julien Grall

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=20240111183410.45566-2-julien@xen.org \
    --to=julien@xen.org \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=jgrall@amazon.com \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --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.