From patchwork Tue Sep 17 18:12:43 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julien Grall X-Patchwork-Id: 11149263 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 501C016B1 for ; Tue, 17 Sep 2019 18:14:49 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3496C21848 for ; Tue, 17 Sep 2019 18:14:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3496C21848 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyM-000891-7j; Tue, 17 Sep 2019 18:13:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyL-00088A-2X for xen-devel@lists.xenproject.org; Tue, 17 Sep 2019 18:13:05 +0000 X-Inumbo-ID: c7808f89-d976-11e9-961d-12813bfff9fa Received: from foss.arm.com (unknown [217.140.110.172]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id c7808f89-d976-11e9-961d-12813bfff9fa; Tue, 17 Sep 2019 18:12:59 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BF1911682; Tue, 17 Sep 2019 11:12:58 -0700 (PDT) Received: from e108454-lin.cambridge.arm.com (e108454-lin.cambridge.arm.com [10.1.196.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 193853F67D; Tue, 17 Sep 2019 11:12:57 -0700 (PDT) From: Julien Grall To: xen-devel@lists.xenproject.org Date: Tue, 17 Sep 2019 19:12:43 +0100 Message-Id: <20190917181244.30027-8-julien.grall@arm.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20190917181244.30027-1-julien.grall@arm.com> References: <20190917181244.30027-1-julien.grall@arm.com> Subject: [Xen-devel] [PATCH v4 7/8] xen/arm32: head: Introduce macros to create table and mapping entry X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Stefano Stabellini , Volodymyr Babchuk MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" At the moment, any update to the boot-pages are open-coded. This is making more difficult to understand the logic of a function as each update roughly requires 6 instructions. To ease the readability, two new macros are introduced: - create_table_entry: Create a page-table entry in a given table. This can work at any level. - create_mapping_entry: Create a mapping entry in a given table. None of the users will require to map at any other level than 3rd (i.e page granularity). So the macro is only supporting 3rd level mapping. Unlike arm64, there are no easy way to have a PC relative address within the range -/+4GB. In order to have the possibility to use the macro in context with MMU on/off, the user needs to tell the state of the MMU. Lastly, take the opportunity to replace open-coded version in setup_fixmap() by the two new macros. The ones in create_page_tables() will be replaced in a follow-up patch. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- The adr_l hack is a bit ugly, but I can't find nicer way to avoid code duplication and improve readability. Changes in v4: - Fix typo - s/tlb/ptlb/ in create_mapping_entry macro - Expand comment on top of addr_l macro - Re-order code in create_mapping_entry Changes in v3: - Patch added --- xen/arch/arm/arm32/head.S | 111 ++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 92 insertions(+), 19 deletions(-) diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S index f58d0fcb80..175f0c9760 100644 --- a/xen/arch/arm/arm32/head.S +++ b/xen/arch/arm/arm32/head.S @@ -50,6 +50,23 @@ .endm /* + * There are no easy way to have a PC relative address within the range + * +/- 4GB of the PC. + * + * This macro workaround it by asking the user to tell whether the MMU + * has been turned on or not. + * + * When the MMU is turned off, we need to apply the physical offset + * (r10) in order to find the associated physical address. + */ +.macro adr_l, dst, sym, mmu + ldr \dst, =\sym + .if \mmu == 0 + add \dst, \dst, r10 + .endif +.endm + +/* * Common register usage in this file: * r0 - * r1 - @@ -342,6 +359,76 @@ cpu_init_done: ENDPROC(cpu_init) /* + * Macro to create a page table entry in \ptbl to \tbl + * + * ptbl: table symbol where the entry will be created + * tbl: table symbol to point to + * virt: virtual address + * shift: #imm page table shift + * mmu: Is the MMU turned on/off. If not specified it will be off + * + * Preserves \virt + * Clobbers r1 - r4 + * + * Also use r10 for the phys offset. + * + * Note that \virt should be in a register other than r1 - r4 + */ +.macro create_table_entry, ptbl, tbl, virt, shift, mmu=0 + lsr r1, \virt, #\shift + mov_w r2, LPAE_ENTRY_MASK + and r1, r1, r2 /* r1 := slot in \tlb */ + lsl r1, r1, #3 /* r1 := slot offset in \tlb */ + + ldr r4, =\tbl + add r4, r4, r10 /* r4 := paddr(\tlb) */ + + mov r2, #PT_PT /* r2:r3 := right for linear PT */ + orr r2, r2, r4 /* + \tlb paddr */ + mov r3, #0 + + adr_l r4, \ptbl, \mmu + + strd r2, r3, [r4, r1] +.endm + +/* + * Macro to create a mapping entry in \tbl to \paddr. Only mapping in 3rd + * level table (i.e page granularity) is supported. + * + * ptbl: table symbol where the entry will be created + * virt: virtual address + * phys: physical address + * type: mapping type. If not specified it will be normal memory (PT_MEM_L3) + * mmu: Is the MMU turned on/off. If not specified it will be off + * + * Preserves \virt, \phys + * Clobbers r1 - r4 + * + * * Also use r10 for the phys offset. + * + * Note that \virt and \paddr should be in other registers than r1 - r4 + * and be distinct. + */ +.macro create_mapping_entry, ptbl, virt, phys, type=PT_MEM_L3, mmu=0 + mov_w r2, LPAE_ENTRY_MASK + lsr r1, \virt, #THIRD_SHIFT + and r1, r1, r2 /* r1 := slot in \tlb */ + lsl r1, r1, #3 /* r1 := slot offset in \tlb */ + + lsr r4, \phys, #THIRD_SHIFT + lsl r4, r4, #THIRD_SHIFT /* r4 := PAGE_ALIGNED(phys) */ + + mov r2, #\type /* r2:r3 := right for section PT */ + orr r2, r2, r4 /* + PAGE_ALIGNED(phys) */ + mov r3, #0 + + adr_l r4, \ptbl, \mmu + + strd r2, r3, [r4, r1] +.endm + +/* * Rebuild the boot pagetable's first-level entries. The structure * is described in mm.c. * @@ -557,31 +644,17 @@ ENDPROC(remove_identity_mapping) * r10: Physical offset * r11: Early UART base physical address * - * Clobbers r1 - r4 + * Clobbers r0 - r4 */ setup_fixmap: #if defined(CONFIG_EARLY_PRINTK) /* Add UART to the fixmap table */ - ldr r1, =xen_fixmap /* r1 := vaddr (xen_fixmap) */ - lsr r2, r11, #THIRD_SHIFT - lsl r2, r2, #THIRD_SHIFT /* 4K aligned paddr of UART */ - orr r2, r2, #PT_UPPER(DEV_L3) - orr r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */ - mov r3, #0x0 - strd r2, r3, [r1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's slot */ + ldr r0, =EARLY_UART_VIRTUAL_ADDRESS + create_mapping_entry xen_fixmap, r0, r11, type=PT_DEV_L3, mmu=1 #endif - /* Map fixmap into boot_second */ - ldr r1, =boot_second /* r1 := vaddr (boot_second) */ - ldr r2, =xen_fixmap - add r2, r2, r10 /* r2 := paddr (xen_fixmap) */ - orr r2, r2, #PT_UPPER(PT) - orr r2, r2, #PT_LOWER(PT) /* r2:r3 := table map of xen_fixmap */ - ldr r4, =FIXMAP_ADDR(0) - mov r4, r4, lsr #(SECOND_SHIFT - 3) /* r4 := Slot for FIXMAP(0) */ - mov r3, #0x0 - strd r2, r3, [r1, r4] /* Map it in the fixmap's slot */ - + mov_w r0, FIXMAP_ADDR(0) + create_table_entry boot_second, xen_fixmap, r0, SECOND_SHIFT, mmu=1 /* Ensure any page table updates made above have occurred. */ dsb nshst