From nobody Fri May 10 17:06:59 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1568744045; cv=none; d=zoho.com; s=zohoarc; b=lN+TSEMYJ8CBe8ZFARx+TwQIJf5ToPDkiW/+tb+8mVpu5hoa72f70jeupsCCnwE05CRxRJurx1tIeJ5NLeqehobKiVhF7uJqCnfI3/tauf0dUXCATkE95OwYa9chHbTCaC69zj0wT+iOGSTkl+I51BD+0Iliilj7pl4116hpBFw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568744045; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=L9ksUQf68OimOzbueDThT9Bz/R5g3eH63mA0mXXoiek=; b=mK+d1VsArkzjBKKk782K12gCNG/Fb6KuuPLaxYwx8k82b1HERuV1Acyhd9VAdrzY+FOuasST2InmHHTsmSlt/DmL+sP5UycoGlPCUMFwlNbNq9I8M66aAN7MJTeRJhIU2mobw6RAgKtEvITl0TKFBybiw6IyYO1Pb79odhtVBQc= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1568744045780239.53192173685807; Tue, 17 Sep 2019 11:14:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyB-00084W-LM; Tue, 17 Sep 2019 18:12:55 +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 1iAHyB-00084K-3O for xen-devel@lists.xenproject.org; Tue, 17 Sep 2019 18:12:55 +0000 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id c44d5d50-d976-11e9-961d-12813bfff9fa; Tue, 17 Sep 2019 18:12:53 +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 46ABD15A2; Tue, 17 Sep 2019 11:12:53 -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 952FD3F67D; Tue, 17 Sep 2019 11:12:52 -0700 (PDT) X-Inumbo-ID: c44d5d50-d976-11e9-961d-12813bfff9fa From: Julien Grall To: xen-devel@lists.xenproject.org Date: Tue, 17 Sep 2019 19:12:37 +0100 Message-Id: <20190917181244.30027-2-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 1/8] xen/arm64: head: Remove 1:1 mapping as soon as it is not used 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The 1:1 mapping may clash with other parts of the Xen virtual memory layout. At the moment, Xen is handling the clash by only creating a mapping to the runtime virtual address before enabling the MMU. The rest of the mappings (such as the fixmap) will be mapped after the MMU is enabled. However, the code doing the mapping is not safe as it replace mapping without using the Break-Before-Make sequence. As the 1:1 mapping can be anywhere in the memory, it is easier to remove all the entries added as soon as the 1:1 mapping is not used rather than adding the Break-Before-Make sequence everywhere. It is difficult to track where exactly the 1:1 mapping was created without a full rework of create_page_tables(). Instead, introduce a new function remove_identity_mapping() will look where is the top-level entry for the 1:1 mapping and remove it. The new function is only called for the boot CPU. Secondary CPUs will switch directly to the runtime page-tables so there are no need to remove the 1:1 mapping. Note that this still doesn't make the Secondary CPUs path safe but it is not making it worst. Note that the TLB flush sequence is same sequence as described in asm-arm/arm32/flushtlb.h with a twist. Per D5-2530 ARM DDI 0487D.a, a dsb nsh is sufficient for local flush. This part of the Arm Arm was missed while reworking the header and therefore a more conservative way were adopted. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- It is very likely we will need to re-introduce the 1:1 mapping to cater secondary CPUs boot and suspend/resume. For now, the attempt is to make boot CPU path fully Arm Arm compliant. Changes in v4: - Fix typo - Remove unnecessary comments - Update the commit message to mention the difference between the sequence described in tlbflush.h and the one used in the code. Changes in v3: - Avoid hardcoding slots Changes in v2: - s/ID map/1:1 mapping/ - Rename remove_id_map() to remove_identity_mapping() - Add missing signed-off-by --- xen/arch/arm/arm64/head.S | 90 +++++++++++++++++++++++++++++++++++++++----= ---- 1 file changed, 75 insertions(+), 15 deletions(-) diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index ba24b05fa2..4c9a69be63 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -33,6 +33,11 @@ #define PT_DEV 0xe71 /* nG=3D1 AF=3D1 SH=3D10 AP=3D01 NS=3D1 ATTR=3D100= T=3D0 P=3D1 */ #define PT_DEV_L3 0xe73 /* nG=3D1 AF=3D1 SH=3D10 AP=3D01 NS=3D1 ATTR=3D100= T=3D1 P=3D1 */ =20 +/* Convenience defines to get slot used by Xen mapping. */ +#define XEN_ZEROETH_SLOT zeroeth_table_offset(XEN_VIRT_START) +#define XEN_FIRST_SLOT first_table_offset(XEN_VIRT_START) +#define XEN_SECOND_SLOT second_table_offset(XEN_VIRT_START) + #define __HEAD_FLAG_PAGE_SIZE ((PAGE_SHIFT - 10) / 2) =20 #define __HEAD_FLAG_PHYS_BASE 1 @@ -312,6 +317,13 @@ real_start_efi: ldr x0, =3Dprimary_switched br x0 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. */ @@ -648,10 +660,67 @@ enable_mmu: ret ENDPROC(enable_mmu) =20 +/* + * Remove the 1:1 map from the page-tables. It is not easy to keep track + * where the 1:1 map was mapped, so we will look for the top-level entry + * exclusive to the 1:1 map and remove it. + * + * Inputs: + * x19: paddr(start) + * + * Clobbers x0 - x1 + */ +remove_identity_mapping: + /* + * Find the zeroeth slot used. Remove the entry from zeroeth + * table if the slot is not XEN_ZEROETH_SLOT. + */ + lsr x1, x19, #ZEROETH_SHIFT /* x1 :=3D zeroeth slot */ + cmp x1, #XEN_ZEROETH_SLOT + beq 1f + /* It is not in slot XEN_ZEROETH_SLOT, remove the entry. */ + ldr x0, =3Dboot_pgtable /* x0 :=3D root table */ + str xzr, [x0, x1, lsl #3] + b identity_mapping_removed + +1: + /* + * Find the first slot used. Remove the entry for the first + * table if the slot is not XEN_FIRST_SLOT. + */ + lsr x1, x19, #FIRST_SHIFT + and x1, x1, #LPAE_ENTRY_MASK /* x1 :=3D first slot */ + cmp x1, #XEN_FIRST_SLOT + beq 1f + /* It is not in slot XEN_FIRST_SLOT, remove the entry. */ + ldr x0, =3Dboot_first /* x0 :=3D first table */ + str xzr, [x0, x1, lsl #3] + b identity_mapping_removed + +1: + /* + * Find the second slot used. Remove the entry for the first + * table if the slot is not XEN_SECOND_SLOT. + */ + lsr x1, x19, #SECOND_SHIFT + and x1, x1, #LPAE_ENTRY_MASK /* x1 :=3D first slot */ + cmp x1, #XEN_SECOND_SLOT + beq identity_mapping_removed + /* It is not in slot 1, remove the entry */ + ldr x0, =3Dboot_second /* x0 :=3D second table */ + str xzr, [x0, x1, lsl #3] + +identity_mapping_removed: + /* See asm-arm/arm64/flushtlb.h for the explanation of the sequenc= e. */ + dsb nshst + tlbi alle2 + dsb nsh + isb + + ret +ENDPROC(remove_identity_mapping) + setup_fixmap: - /* Now we can install the fixmap and dtb mappings, since we - * don't need the 1:1 map any more */ - dsb sy #if defined(CONFIG_EARLY_PRINTK) /* Fixmap is only used by early printk */ /* Add UART to the fixmap table */ ldr x1, =3Dxen_fixmap /* x1 :=3D vaddr (xen_fixmap) */ @@ -669,19 +738,10 @@ setup_fixmap: ldr x1, =3DFIXMAP_ADDR(0) lsr x1, x1, #(SECOND_SHIFT - 3) /* x1 :=3D Slot for FIXMAP(0) = */ str x2, [x4, x1] /* Map it in the fixmap's slot */ -#endif =20 - /* - * Flush the TLB in case the 1:1 mapping happens to clash with - * the virtual addresses used by the fixmap or DTB. - */ - dsb sy /* Ensure any page table updates made= above - * have occurred. */ - - isb - tlbi alle2 - dsb sy /* Ensure completion of TLB flush */ - isb + /* Ensure any page table updates made above have occurred. */ + dsb nshst +#endif ret ENDPROC(setup_fixmap) =20 --=20 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel From nobody Fri May 10 17:06:59 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1568744047; cv=none; d=zoho.com; s=zohoarc; b=RHPcnq2K6MdwRJbzFYivh0oLJJjuqbbJxIihNlqy6xOI+K/EjoFiibo1rnXqWbbJJXeDaZy18rOEx0hbFuAZU8H83jiUNQjWCvNUVgzPpPCxPUIIfNjx+FirAVheWab0kAzqzyitifZHdjqNpW/AC4pfH+l3c/uDoq11VSprMRQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568744047; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=1Q+8aL6pIfOCEXeMs13KNWjNzevsh18XrcTZjkfXnog=; b=X6iffHsPHIyCWW6uoKosGQUllZUJOq9YtHP2zxQNHX20BTs2MOheeQSNtuI/ndjFQVw2Im2cq8lJvUj4oOhRETJarSLne0wLM9KPk01frZUHe5HN2Fx8DyMnyHV0TeBJ95C4AX0gyIrkIcnwl50kBrFmPvbMjgELvRuLHRC2geo= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1568744047952403.28869934352304; Tue, 17 Sep 2019 11:14:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyC-00084r-Vr; Tue, 17 Sep 2019 18:12:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyC-00084c-4M for xen-devel@lists.xenproject.org; Tue, 17 Sep 2019 18:12:56 +0000 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id c4dc6fea-d976-11e9-b76c-bc764e2007e4; Tue, 17 Sep 2019 18:12:54 +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 2D0AC1650; Tue, 17 Sep 2019 11:12:54 -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 7BB223F67D; Tue, 17 Sep 2019 11:12:53 -0700 (PDT) X-Inumbo-ID: c4dc6fea-d976-11e9-b76c-bc764e2007e4 From: Julien Grall To: xen-devel@lists.xenproject.org Date: Tue, 17 Sep 2019 19:12:38 +0100 Message-Id: <20190917181244.30027-3-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 2/8] xen/arm64: head: Rework and document setup_fixmap() 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" At the moment, the fixmap table is only hooked when earlyprintk is used. This is fine today because in C land, the fixmap is not used by anyone until the the boot CPU is switching to the runtime page-tables. In the future, the boot CPU will not switch between page-tables to avoid TLB incoherency. Thus, the fixmap table will need to be always hooked before any use. Let's start doing it now in setup_fixmap(). Lastly, document the behavior and the main registers usage within the function. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v3: - Fix typo in the commit message - Add Stefano's Acked-by Changes in v2: - Update the comment to reflect that we clobbers x1 - x4 and not x0 - x1. - Add the list of input registers - s/ID map/1:1 mapping/ - Reword the commit message --- xen/arch/arm/arm64/head.S | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index 4c9a69be63..177cec4e45 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -720,8 +720,21 @@ identity_mapping_removed: ret ENDPROC(remove_identity_mapping) =20 +/* + * 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: + * x20: Physical offset + * x23: Early UART base physical address + * + * Clobbers x1 - x4 + */ setup_fixmap: -#if defined(CONFIG_EARLY_PRINTK) /* Fixmap is only used by early printk */ +#ifdef CONFIG_EARLY_PRINTK /* Add UART to the fixmap table */ ldr x1, =3Dxen_fixmap /* x1 :=3D vaddr (xen_fixmap) */ lsr x2, x23, #THIRD_SHIFT @@ -729,6 +742,7 @@ setup_fixmap: mov x3, #PT_DEV_L3 orr x2, x2, x3 /* x2 :=3D 4K dev map including UART = */ str x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap'= s slot */ +#endif =20 /* Map fixmap into boot_second */ ldr x4, =3Dboot_second /* x4 :=3D vaddr (boot_second) */ @@ -741,7 +755,7 @@ setup_fixmap: =20 /* Ensure any page table updates made above have occurred. */ dsb nshst -#endif + ret ENDPROC(setup_fixmap) =20 --=20 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel From nobody Fri May 10 17:06:59 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1568744048; cv=none; d=zoho.com; s=zohoarc; b=Ot11d3Jm5rL763OUWPli01PB8E9qLNzUehmnE6Gd07Cv8sViSKmUlryETZ9qOGOhkG01SUr42lQn5bOTiaEYcz64rEfJVaX7PsIwEEi4q3SfC+Vo1SuuvyCfQ8d5/PIM5Tdc2maq+MgsWx9pRZc4BaTUG0OA431si4f25s+CdlM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568744048; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=dhBxSh4n3SVwv34XNMrTJDJA35wmRijYLywHYI1rXJs=; b=PivpGUk7JK24Bj12D8ldXeipCqslsqk135nOpYvewdqpquCJ8bRO69gwnkJgh9iRAgKEptcUjS7irCK/un32FRNgqqnLEYyLj9AFFwo/Ju87PUH4VNl8Yo16xWGXI4i82fe5HXLLdFb8BZjK7HY+lOCAmldWOjDicHD/yKDhI5M= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 156874404885830.08007327614223; Tue, 17 Sep 2019 11:14:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyH-00086A-Bu; Tue, 17 Sep 2019 18:13:01 +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 1iAHyG-00085i-2D for xen-devel@lists.xenproject.org; Tue, 17 Sep 2019 18:13:00 +0000 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id c573aca2-d976-11e9-961d-12813bfff9fa; Tue, 17 Sep 2019 18:12:55 +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 16A8B1682; Tue, 17 Sep 2019 11:12:55 -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 650FF3F67D; Tue, 17 Sep 2019 11:12:54 -0700 (PDT) X-Inumbo-ID: c573aca2-d976-11e9-961d-12813bfff9fa From: Julien Grall To: xen-devel@lists.xenproject.org Date: Tue, 17 Sep 2019 19:12:39 +0100 Message-Id: <20190917181244.30027-4-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 3/8] xen/arm32: head: Remove 1:1 mapping as soon as it is not used 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The 1:1 mapping may clash with other parts of the Xen virtual memory layout. At the moment, Xen is handling the clash by only creating a mapping to the runtime virtual address before enabling the MMU. The rest of the mappings (such as the fixmap) will be mapped after the MMU is enabled. However, the code doing the mapping is not safe as it replace mapping without using the Break-Before-Make sequence. As the 1:1 mapping can be anywhere in the memory, it is easier to remove all the entries added as soon as the 1:1 mapping is not used rather than adding the Break-Before-Make sequence everywhere. It is difficult to track where exactly the 1:1 mapping was created without a full rework of create_page_tables(). Instead, introduce a new function remove_identity_mapping() will look where is the top-level entry for the 1:1 mapping and remove it. The new function is only called for the boot CPU. Secondary CPUs will switch directly to the runtime page-tables so there are no need to remove the 1:1 mapping. Note that this still doesn't make the Secondary CPUs path safe but it is not making it worst. Note that the TLB flush sequence is same sequence as described in asm-arm/arm32/flushtlb.h with a twist. Per G5-5532 ARM DDI 0487D.a, a dsb nsh is sufficient for local flushed. Note the section is from the AArch32 Armv8 spec, I wasn't able to find the same exact section in the Armv7 spec but this is dotted as local operations only applies to non-shareable domain. This was missed while reworking the header and therefore a more conservative way were adopted. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- It is very likely we will need to re-introduce the 1:1 mapping to cater secondary CPUs boot and suspend/resume. For now, the attempt is to make boot CPU path fully Arm Arm compliant. Changes in v4: - Fix typo - Fix indentation - Remove unnecessary comments Changes in v3: - Remove unused label - Avoid harcoding slots Changes in v2: - Patch added --- xen/arch/arm/arm32/head.S | 84 +++++++++++++++++++++++++++++++++++++------= ---- 1 file changed, 67 insertions(+), 17 deletions(-) diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S index 999233452d..65b7e0d711 100644 --- a/xen/arch/arm/arm32/head.S +++ b/xen/arch/arm/arm32/head.S @@ -32,6 +32,10 @@ #define PT_UPPER(x) (PT_##x & 0xf00) #define PT_LOWER(x) (PT_##x & 0x0ff) =20 +/* Convenience defines to get slot used by Xen mapping. */ +#define XEN_FIRST_SLOT first_table_offset(XEN_VIRT_START) +#define XEN_SECOND_SLOT second_table_offset(XEN_VIRT_START) + #if (defined (CONFIG_EARLY_PRINTK)) && (defined (EARLY_PRINTK_INC)) #include EARLY_PRINTK_INC #endif @@ -157,6 +161,13 @@ past_zImage: ldr r0, =3Dprimary_switched mov pc, r0 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. */ @@ -481,12 +492,61 @@ enable_mmu: mov pc, lr ENDPROC(enable_mmu) =20 -setup_fixmap: +/* + * Remove the 1:1 map from the page-tables. It is not easy to keep track + * where the 1:1 map was mapped, so we will look for the top-level entry + * exclusive to the 1:1 map and remove it. + * + * Inputs: + * r9 : paddr(start) + * + * Clobbers r0 - r3 + */ +remove_identity_mapping: + /* r2:r3 :=3D invalid page-table entry */ + mov r2, #0x0 + mov r3, #0x0 /* - * Now we can install the fixmap and dtb mappings, since we - * don't need the 1:1 map any more + * Find the first slot used. Remove the entry for the first + * table if the slot is not XEN_FIRST_SLOT. */ - dsb + lsr r1, r9, #FIRST_SHIFT + mov_w r0, LPAE_ENTRY_MASK + and r1, r1, r0 /* r1 :=3D first slot */ + cmp r1, #XEN_FIRST_SLOT + beq 1f + /* It is not in slot 0, remove the entry */ + ldr r0, =3Dboot_pgtable /* r0 :=3D root table */ + lsl r1, r1, #3 /* r1 :=3D Slot offset */ + strd r2, r3, [r0, r1] + b identity_mapping_removed + +1: + /* + * Find the second slot used. Remove the entry for the first + * table if the slot is not XEN_SECOND_SLOT. + */ + lsr r1, r9, #SECOND_SHIFT + mov_w r0, LPAE_ENTRY_MASK + and r1, r1, r0 /* r1 :=3D second slot */ + cmp r1, #XEN_SECOND_SLOT + beq identity_mapping_removed + /* It is not in slot 1, remove the entry */ + ldr r0, =3Dboot_second /* r0 :=3D second table */ + lsl r1, r1, #3 /* r1 :=3D Slot offset */ + strd r2, r3, [r0, r1] + +identity_mapping_removed: + /* See asm-arm/arm32/flushtlb.h for the explanation of the sequenc= e. */ + dsb nshst + mcr CP32(r0, TLBIALLH) + dsb nsh + isb + + mov pc, lr +ENDPROC(remove_identity_mapping) + +setup_fixmap: #if defined(CONFIG_EARLY_PRINTK) /* Fixmap is only used by early printk */ /* Add UART to the fixmap table */ ldr r1, =3Dxen_fixmap /* r1 :=3D vaddr (xen_fixmap) */ @@ -496,7 +556,6 @@ setup_fixmap: orr r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 :=3D 4K dev map including= UART */ mov r3, #0x0 strd r2, r3, [r1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fix= map's slot */ -1: =20 /* Map fixmap into boot_second */ ldr r1, =3Dboot_second /* r1 :=3D vaddr (boot_second) */ @@ -508,19 +567,10 @@ setup_fixmap: mov r4, r4, lsr #(SECOND_SHIFT - 3) /* r4 :=3D Slot for FIXMAP= (0) */ mov r3, #0x0 strd r2, r3, [r1, r4] /* Map it in the fixmap's slot */ -#endif - - /* - * Flush the TLB in case the 1:1 mapping happens to clash with - * the virtual addresses used by the fixmap or DTB. - */ - dsb /* Ensure any page table updates made= above - * have occurred. */ =20 - isb - mcr CP32(r0, TLBIALLH) /* Flush hypervisor TLB */ - dsb /* Ensure completion of TLB flush */ - isb + /* Ensure any page table updates made above have occurred. */ + dsb nshst +#endif mov pc, lr ENDPROC(setup_fixmap) =20 --=20 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel From nobody Fri May 10 17:06:59 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1568744049; cv=none; d=zoho.com; s=zohoarc; b=isoSbYZEHknyYsvqkii6C4VBn4bPCDyfsfRedoUlRyT9BSGPXeKpXMBiKfkXRuLjzIhrtTt3bLL3gVUXpADPgY1nYwmruBv8deVpCyq83GJ+3ffYqCJtQsXe7o7hklUQnGMtR3RUtvWwO6LC0f6/nfJsjEHjsnB+WDHLZBPu3Ww= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568744049; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=zZMwVCZX9qh/OgiGzKCSvi/GBjmXx01DkK6ExofNJUM=; b=IGFJxtQ5kknMdC/Gb9l/kV2/LTyH4llol6M147mXCAWerqKs0605JW2QrSTcavI6qWox/b5AcAeAecPTe0B2M6p3kKOPuxEXNAPL93D4Ojq6G3qZqy8uixp4HPV258Rwfs8bCDGimLXmYEzSbLeukOppBhxDDGpr+bb6MwSMBzs= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1568744049387350.28399576014044; Tue, 17 Sep 2019 11:14:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyH-00086Z-So; Tue, 17 Sep 2019 18:13:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyH-000863-3x for xen-devel@lists.xenproject.org; Tue, 17 Sep 2019 18:13:01 +0000 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id c5efc576-d976-11e9-b76c-bc764e2007e4; Tue, 17 Sep 2019 18:12:56 +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 F14F1168F; Tue, 17 Sep 2019 11:12:55 -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 4BDDA3F67D; Tue, 17 Sep 2019 11:12:55 -0700 (PDT) X-Inumbo-ID: c5efc576-d976-11e9-b76c-bc764e2007e4 From: Julien Grall To: xen-devel@lists.xenproject.org Date: Tue, 17 Sep 2019 19:12:40 +0100 Message-Id: <20190917181244.30027-5-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 4/8] xen/arm32: head: Rework and document setup_fixmap() 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" At the moment, the fixmap table is only hooked when earlyprintk is used. This is fine today because in C land, the fixmap is not used by anyone until the the boot CPU is switching to the runtime page-tables. In the future, the boot CPU will not switch between page-tables to avoid TLB incoherency. Thus, the fixmap table will need to be always hooked beofre any use. Let's start doing it now in setup_fixmap(). Lastly, document the behavior and the main registers usage within the function. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v3: - The unused label is now removed in the previous patch - Add Stefano's reviewed-by Changes in v2: - Patch added --- xen/arch/arm/arm32/head.S | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S index 65b7e0d711..f58d0fcb80 100644 --- a/xen/arch/arm/arm32/head.S +++ b/xen/arch/arm/arm32/head.S @@ -546,8 +546,21 @@ identity_mapping_removed: mov pc, lr ENDPROC(remove_identity_mapping) =20 +/* + * 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 r1 - r4 + */ setup_fixmap: -#if defined(CONFIG_EARLY_PRINTK) /* Fixmap is only used by early printk */ +#if defined(CONFIG_EARLY_PRINTK) /* Add UART to the fixmap table */ ldr r1, =3Dxen_fixmap /* r1 :=3D vaddr (xen_fixmap) */ lsr r2, r11, #THIRD_SHIFT @@ -556,6 +569,7 @@ setup_fixmap: orr r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 :=3D 4K dev map including= UART */ mov r3, #0x0 strd r2, r3, [r1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fix= map's slot */ +#endif =20 /* Map fixmap into boot_second */ ldr r1, =3Dboot_second /* r1 :=3D vaddr (boot_second) */ @@ -570,7 +584,7 @@ setup_fixmap: =20 /* Ensure any page table updates made above have occurred. */ dsb nshst -#endif + mov pc, lr ENDPROC(setup_fixmap) =20 --=20 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel From nobody Fri May 10 17:06:59 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1568744060; cv=none; d=zoho.com; s=zohoarc; b=M4yiTjoLdaxcU5SJmGENYGkp6VC9RqtsoC94QR8jigOomMoTm6tA6sGwUh5DVyxQWNYyMAKwpFUDd8cDh9zfWZjUEekNgCIM5cI+LmJRykYdITNX+EW31RalYIV7dh/1YAdpMsxOr6kv5G4v3ht+FdwS7SxzrNuPTH7cEB9XZB4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568744060; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=OnaxXolAF/k4Wo0pAl49X731H+fnwT+HMnNTsfiiSX8=; b=l4MvYjEfCSBJAdTUFGcYRLMinvoAqT6KY47xmXY6NQVtDOuurPOQW+jey51ihqaJ3/weZ9iCZpNyEB44AdKNfP/9VJi37t/TxTyv08ElzqzT12CxJSKq7t6KvXAqNFtNiaYyb12TIN2jaWWHib9bS877r6qEgyfBB4tg7CtqLtY= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1568744060526104.54177138862849; Tue, 17 Sep 2019 11:14:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyR-0008Dd-Vp; Tue, 17 Sep 2019 18:13:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyR-0008Cf-4B for xen-devel@lists.xenproject.org; Tue, 17 Sep 2019 18:13:11 +0000 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id c677c192-d976-11e9-b76c-bc764e2007e4; Tue, 17 Sep 2019 18:12:57 +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 D76751000; Tue, 17 Sep 2019 11:12:56 -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 31F303F67D; Tue, 17 Sep 2019 11:12:56 -0700 (PDT) X-Inumbo-ID: c677c192-d976-11e9-b76c-bc764e2007e4 From: Julien Grall To: xen-devel@lists.xenproject.org Date: Tue, 17 Sep 2019 19:12:41 +0100 Message-Id: <20190917181244.30027-6-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 5/8] xen/arm64: 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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. Furthermore, the two macros are capable to work independently of 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 --- Changes in v4: - Fix typo - /tlb/ptlb/ in create_mapping_entry macro Changes in v3: - Patch added --- xen/arch/arm/arm64/head.S | 83 ++++++++++++++++++++++++++++++++++++++-----= ---- 1 file changed, 67 insertions(+), 16 deletions(-) diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index 177cec4e45..2cce342217 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -492,6 +492,68 @@ cpu_init: ENDPROC(cpu_init) =20 /* + * 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 + * tmp1: scratch register + * tmp2: scratch register + * tmp3: scratch register + * + * Preserves \virt + * Clobbers \tmp1, \tmp2, \tmp3 + * + * Also use x20 for the phys offset. + * + * Note that all parameters using registers should be distinct. + */ +.macro create_table_entry, ptbl, tbl, virt, shift, tmp1, tmp2, tmp3 + lsr \tmp1, \virt, #\shift + and \tmp1, \tmp1, #LPAE_ENTRY_MASK/* \tmp1 :=3D slot in \tlb */ + + load_paddr \tmp2, \tbl + mov \tmp3, #PT_PT /* \tmp3 :=3D right for linear= PT */ + orr \tmp3, \tmp3, \tmp2 /* + \tlb paddr */ + + adr_l \tmp2, \ptbl + + str \tmp3, [\tmp2, \tmp1, lsl #3] +.endm + +/* + * Macro to create a mapping entry in \tbl to \phys. 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 (should be page aligned) + * tmp1: scratch register + * tmp2: scratch register + * tmp3: scratch register + * type: mapping type. If not specified it will be normal memory (PT_ME= M_L3) + * + * Preserves \virt, \phys + * Clobbers \tmp1, \tmp2, \tmp3 + * + * Note that all parameters using registers should be distinct. + */ +.macro create_mapping_entry, ptbl, virt, phys, tmp1, tmp2, tmp3, type=3DPT= _MEM_L3 + and \tmp3, \phys, #THIRD_MASK /* \tmp3 :=3D PAGE_ALIGNED(phy= s) */ + + lsr \tmp1, \virt, #THIRD_SHIFT + and \tmp1, \tmp1, #LPAE_ENTRY_MASK/* \tmp1 :=3D slot in \tlb */ + + mov \tmp2, #\type /* \tmp2 :=3D right for sectio= n PT */ + orr \tmp2, \tmp2, \tmp3 /* + PAGE_ALIGNED(phy= s) */ + + adr_l \tmp3, \ptbl + + str \tmp2, [\tmp3, \tmp1, lsl #3] +.endm + +/* * Rebuild the boot pagetable's first-level entries. The structure * is described in mm.c. * @@ -731,28 +793,17 @@ ENDPROC(remove_identity_mapping) * x20: Physical offset * x23: Early UART base physical address * - * Clobbers x1 - x4 + * Clobbers x0 - x3 */ setup_fixmap: #ifdef CONFIG_EARLY_PRINTK /* Add UART to the fixmap table */ - ldr x1, =3Dxen_fixmap /* x1 :=3D vaddr (xen_fixmap) */ - lsr x2, x23, #THIRD_SHIFT - lsl x2, x2, #THIRD_SHIFT /* 4K aligned paddr of UART */ - mov x3, #PT_DEV_L3 - orr x2, x2, x3 /* x2 :=3D 4K dev map including UART = */ - str x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap'= s slot */ + ldr x0, =3DEARLY_UART_VIRTUAL_ADDRESS + create_mapping_entry xen_fixmap, x0, x23, x1, x2, x3, type=3DPT_DE= V_L3 #endif - /* Map fixmap into boot_second */ - ldr x4, =3Dboot_second /* x4 :=3D vaddr (boot_second) */ - load_paddr x2, xen_fixmap - mov x3, #PT_PT - orr x2, x2, x3 /* x2 :=3D table map of xen_fixmap */ - ldr x1, =3DFIXMAP_ADDR(0) - lsr x1, x1, #(SECOND_SHIFT - 3) /* x1 :=3D Slot for FIXMAP(0) = */ - str x2, [x4, x1] /* Map it in the fixmap's slot */ - + ldr x0, =3DFIXMAP_ADDR(0) + create_table_entry boot_second, xen_fixmap, x0, SECOND_SHIFT, x1, = x2, x3 /* Ensure any page table updates made above have occurred. */ dsb nshst =20 --=20 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel From nobody Fri May 10 17:06:59 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1568744068; cv=none; d=zoho.com; s=zohoarc; b=Ep/ajmise0+Or1uxqWiG5/5Bc+3Crner/GDCvL/5OQRnmP/FlTOd6c5MO6koM4EZZRg9KXfA/be0cSTC/7+FurKkW8TcGUZyw7mi5a8PZrNacs1pM6EJcTRSGu+8vPcwSmeHZGeQrQBgneh6OmudmfIdaEhYjl3JNWrUU6Mo3DE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568744068; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=uuF30bMSmTk/90QirTDHbvo3U6ssCczVm7AvcZU8ElI=; b=MwFEOtDZnz+DNPC8wEn2NznNHgF1ArXwLEJlM2eyv+M50JRo3O9ab2FipKsBiIC+AFnicpDNA6D8nn66y8u2HSjpWKDTFwFDCurjEo2SnL0Bmn7vCJY2dx+XHsoF2INMF0mricNh8R4zEEBPGYOdj1wLKqLbrP4wcCi1yUOxFls= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1568744068581347.5089406328426; Tue, 17 Sep 2019 11:14:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyX-0008I9-Es; Tue, 17 Sep 2019 18:13:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyW-0008H7-4r for xen-devel@lists.xenproject.org; Tue, 17 Sep 2019 18:13:16 +0000 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id c707f1f4-d976-11e9-b76c-bc764e2007e4; Tue, 17 Sep 2019 18:12:58 +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 D8A1315A2; Tue, 17 Sep 2019 11:12:57 -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 181703F67D; Tue, 17 Sep 2019 11:12:56 -0700 (PDT) X-Inumbo-ID: c707f1f4-d976-11e9-b76c-bc764e2007e4 From: Julien Grall To: xen-devel@lists.xenproject.org Date: Tue, 17 Sep 2019 19:12:42 +0100 Message-Id: <20190917181244.30027-7-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 6/8] xen/arm64: head: Use a page mapping for the 1:1 mapping in create_page_tables() 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" At the moment the function create_page_tables() will use 1GB/2MB mapping for the identity mapping. As we don't know what is present before and after Xen in memory, we may end up to map device/reserved-memory with cacheable memory. This may result to mismatched attributes as other users may access the same region differently. To prevent any issues, we should only map the strict minimum in the 1:1 mapping. A check in xen.lds.S already guarantees anything necessary for turning on the MMU fits in a page (at the moment 4K). As only one page will be mapped for the 1:1 mapping, it is necessary to pre-allocate a page for the 3rd level table. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v4: - Don't pre-link the page-tables for the 1:1 mapping. Instead only link what's necessary. Changes in v3: - Patch added --- xen/arch/arm/arm64/head.S | 166 ++++++++++++++++++------------------------= ---- xen/arch/arm/mm.c | 2 + 2 files changed, 68 insertions(+), 100 deletions(-) diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index 2cce342217..e5015f93a2 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -566,100 +566,17 @@ ENDPROC(cpu_init) * x19: paddr(start) * x20: phys offset * - * Clobbers x0 - x4, x25 - * - * Register usage within this function: - * x25: Identity map in place + * Clobbers x0 - x4 */ create_page_tables: - /* - * If Xen is loaded at exactly XEN_VIRT_START then we don't - * need an additional 1:1 mapping, the virtual mapping will - * suffice. - */ - cmp x19, #XEN_VIRT_START - cset x25, eq /* x25 :=3D identity map in place, or= not */ - - load_paddr x4, boot_pgtable - - /* Setup boot_pgtable: */ - load_paddr x1, boot_first - - /* ... map boot_first in boot_pgtable[0] */ - mov x3, #PT_PT /* x2 :=3D table map of boot_first */ - orr x2, x1, x3 /* + rights for linear PT */ - str x2, [x4, #0] /* Map it in slot 0 */ - - /* ... map of paddr(start) in boot_pgtable+boot_first_id */ - lsr x1, x19, #ZEROETH_SHIFT/* Offset of base paddr in boot_pgtab= le */ - cbz x1, 1f /* It's in slot 0, map in boot_first - * or boot_second later on */ + /* Prepare the page-tables for mapping Xen */ + ldr x0, =3DXEN_VIRT_START + create_table_entry boot_pgtable, boot_first, x0, ZEROETH_SHIFT, x1= , x2, x3 + create_table_entry boot_first, boot_second, x0, FIRST_SHIFT, x1, x= 2, x3 + create_table_entry boot_second, boot_third, x0, SECOND_SHIFT, x1, = x2, x3 =20 - /* - * Level zero does not support superpage mappings, so we have - * to use an extra first level page in which we create a 1GB mappi= ng. - */ - load_paddr x2, boot_first_id - - mov x3, #PT_PT /* x2 :=3D table map of boot_first_id= */ - orr x2, x2, x3 /* + rights for linear PT */ - str x2, [x4, x1, lsl #3] - - load_paddr x4, boot_first_id - - lsr x1, x19, #FIRST_SHIFT /* x1 :=3D Offset of base paddr in bo= ot_first_id */ - lsl x2, x1, #FIRST_SHIFT /* x2 :=3D Base address for 1GB mappi= ng */ - mov x3, #PT_MEM /* x2 :=3D Section map */ - orr x2, x2, x3 - and x1, x1, #LPAE_ENTRY_MASK /* x1 :=3D Slot offset */ - str x2, [x4, x1, lsl #3] /* Mapping of paddr(start) */ - mov x25, #1 /* x25 :=3D identity map now in place= */ - -1: /* Setup boot_first: */ - load_paddr x4, boot_first /* Next level into boot_first */ - - /* ... map boot_second in boot_first[0] */ - load_paddr x1, boot_second - mov x3, #PT_PT /* x2 :=3D table map of boot_second */ - orr x2, x1, x3 /* + rights for linear PT */ - str x2, [x4, #0] /* Map it in slot 0 */ - - /* ... map of paddr(start) in boot_first */ - cbnz x25, 1f /* x25 is set if already created */ - lsr x2, x19, #FIRST_SHIFT /* x2 :=3D Offset of base paddr in bo= ot_first */ - and x1, x2, #LPAE_ENTRY_MASK /* x1 :=3D Slot to use */ - cbz x1, 1f /* It's in slot 0, map in boot_second= */ - - lsl x2, x2, #FIRST_SHIFT /* Base address for 1GB mapping */ - mov x3, #PT_MEM /* x2 :=3D Section map */ - orr x2, x2, x3 - str x2, [x4, x1, lsl #3] /* Create mapping of paddr(start)*/ - mov x25, #1 /* x25 :=3D identity map now in place= */ - -1: /* Setup boot_second: */ - load_paddr x4, boot_second - - /* ... map boot_third in boot_second[1] */ - load_paddr x1, boot_third - mov x3, #PT_PT /* x2 :=3D table map of boot_third */ - orr x2, x1, x3 /* + rights for linear PT */ - str x2, [x4, #8] /* Map it in slot 1 */ - - /* ... map of paddr(start) in boot_second */ - cbnz x25, 1f /* x25 is set if already created */ - lsr x2, x19, #SECOND_SHIFT /* x2 :=3D Offset of base paddr in bo= ot_second */ - and x1, x2, #LPAE_ENTRY_MASK /* x1 :=3D Slot to use */ - cmp x1, #1 - b.eq virtphys_clash /* It's in slot 1, which we cannot ha= ndle */ - - lsl x2, x2, #SECOND_SHIFT /* Base address for 2MB mapping */ - mov x3, #PT_MEM /* x2 :=3D Section map */ - orr x2, x2, x3 - str x2, [x4, x1, lsl #3] /* Create mapping of paddr(start)*/ - mov x25, #1 /* x25 :=3D identity map now in place= */ - -1: /* Setup boot_third: */ - load_paddr x4, boot_third + /* Map Xen */ + adr_l x4, boot_third =20 lsr x2, x19, #THIRD_SHIFT /* Base address for 4K mapping */ lsl x2, x2, #THIRD_SHIFT @@ -674,21 +591,70 @@ create_page_tables: cmp x1, #(LPAE_ENTRIES<<3) /* 512 entries per page */ b.lt 1b =20 - /* Defer fixmap and dtb mapping until after paging enabled, to - * avoid them clashing with the 1:1 mapping. */ + /* + * If Xen is loaded at exactly XEN_VIRT_START then we don't + * need an additional 1:1 mapping, the virtual mapping will + * suffice. + */ + cmp x19, #XEN_VIRT_START + bne 1f + ret +1: + /* + * Setup the 1:1 mapping so we can turn the MMU on. Note that + * only the first page of Xen will be part of the 1:1 mapping. + */ + + /* + * Find the zeroeth slot used. If the slot is not + * XEN_ZEROETH_SLOT, then the 1:1 mapping will use its own set of + * page-tables from the first level. + */ + lsr x0, x19, #ZEROETH_SHIFT /* x0 :=3D zeroeth slot */ + cmp x0, #XEN_ZEROETH_SLOT + beq 1f + create_table_entry boot_pgtable, boot_first_id, x19, ZEROETH_SHIFT= , x0, x1, x2 + b link_from_first_id + +1: + /* + * Find the first slot used. If the slot is not XEN_FIRST_SLOT, + * then the 1:1 mapping will use its own set of page-tables from + * the second level. + */ + lsr x0, x19, #FIRST_SHIFT + and x0, x0, #LPAE_ENTRY_MASK /* x0 :=3D first slot */ + cmp x0, #XEN_FIRST_SLOT + beq 1f + create_table_entry boot_first, boot_second_id, x19, FIRST_SHIFT, x= 0, x1, x2 + b link_from_second_id =20 - /* boot pagetable setup complete */ +1: + /* + * Find the second slot used. If the slot is XEN_SECOND_SLOT, then= the + * 1:1 mapping will use its own set of page-tables from the + * third level. For slot XEN_SECOND_SLOT, Xen is not yet able to h= andle + * it. + */ + lsr x0, x19, #SECOND_SHIFT + and x0, x0, #LPAE_ENTRY_MASK /* x0 :=3D first slot */ + cmp x0, #XEN_SECOND_SLOT + beq virtphys_clash + create_table_entry boot_second, boot_third_id, x19, SECOND_SHIFT, = x0, x1, x2 + b link_from_third_id + +link_from_first_id: + create_table_entry boot_first_id, boot_second_id, x19, FIRST_SHIFT= , x0, x1, x2 +link_from_second_id: + create_table_entry boot_second_id, boot_third_id, x19, SECOND_SHIF= T, x0, x1, x2 +link_from_third_id: + create_mapping_entry boot_third_id, x19, x19, x0, x1, x2 + ret =20 - cbnz x25, 1f /* Did we manage to create an identit= y mapping ? */ - PRINT("Unable to build boot page tables - Failed to identity map X= en.\r\n") - b fail virtphys_clash: /* Identity map clashes with boot_third, which we cannot handle ye= t */ PRINT("- Unable to build boot page tables - virt and phys addresse= s clash. -\r\n") b fail - -1: - ret ENDPROC(create_page_tables) =20 /* diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 65552da4ba..72ffea7472 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -105,6 +105,8 @@ DEFINE_BOOT_PAGE_TABLE(boot_pgtable); #ifdef CONFIG_ARM_64 DEFINE_BOOT_PAGE_TABLE(boot_first); DEFINE_BOOT_PAGE_TABLE(boot_first_id); +DEFINE_BOOT_PAGE_TABLE(boot_second_id); +DEFINE_BOOT_PAGE_TABLE(boot_third_id); #endif DEFINE_BOOT_PAGE_TABLE(boot_second); DEFINE_BOOT_PAGE_TABLE(boot_third); --=20 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel From nobody Fri May 10 17:06:59 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1568744055; cv=none; d=zoho.com; s=zohoarc; b=XfTkChQ0Oh6sPHlL884euFeZ83aq8z+3uy3teko4ryic2y3sOpNIqCYDzsrD2boDl4L4v4hZdFxSEcOX5hZG7BVhtXQUGR9db04je0/S62jcxCAZ0fm0KKQxWMfucZgZ+sQtAfLk3f1IaSgEmGWVfjdi7/NnsFXkx5zwfQvJPz0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568744055; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=zz9MOVKq6todQYmkVvA2IEUalZltxpEb2xCQHxZmc1o=; b=ktoNhXW3ePdhn+Twj3cXlEld9eZeCXnm7exuRbgnOlO1EVbJ8i7kiS2Gxbx94AJheNZ57OPjyRnORv9nTREvan1FGqBN+qY2j9IB5efBX/oVYzIgCjdeTgYDne2D7y85FXrOFEc3/xaI/1Gn+bRmE2m5KI5P1ZzxU5gNOiRYTXU= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1568744055797618.2044214088262; Tue, 17 Sep 2019 11:14:15 -0700 (PDT) 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 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) X-Inumbo-ID: c7808f89-d976-11e9-961d-12813bfff9fa 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 =20 /* + * 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, =3D\sym + .if \mmu =3D=3D 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) =20 /* + * 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=3D0 + lsr r1, \virt, #\shift + mov_w r2, LPAE_ENTRY_MASK + and r1, r1, r2 /* r1 :=3D slot in \tlb */ + lsl r1, r1, #3 /* r1 :=3D slot offset in \tlb */ + + ldr r4, =3D\tbl + add r4, r4, r10 /* r4 :=3D paddr(\tlb) */ + + mov r2, #PT_PT /* r2:r3 :=3D 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_ME= M_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=3DPT_MEM_L3, mmu=3D0 + mov_w r2, LPAE_ENTRY_MASK + lsr r1, \virt, #THIRD_SHIFT + and r1, r1, r2 /* r1 :=3D slot in \tlb */ + lsl r1, r1, #3 /* r1 :=3D slot offset in \tlb */ + + lsr r4, \phys, #THIRD_SHIFT + lsl r4, r4, #THIRD_SHIFT /* r4 :=3D PAGE_ALIGNED(phys) */ + + mov r2, #\type /* r2:r3 :=3D 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, =3Dxen_fixmap /* r1 :=3D 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 :=3D 4K dev map including= UART */ - mov r3, #0x0 - strd r2, r3, [r1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fix= map's slot */ + ldr r0, =3DEARLY_UART_VIRTUAL_ADDRESS + create_mapping_entry xen_fixmap, r0, r11, type=3DPT_DEV_L3, mmu=3D1 #endif - /* Map fixmap into boot_second */ - ldr r1, =3Dboot_second /* r1 :=3D vaddr (boot_second) */ - ldr r2, =3Dxen_fixmap - add r2, r2, r10 /* r2 :=3D paddr (xen_fixmap) */ - orr r2, r2, #PT_UPPER(PT) - orr r2, r2, #PT_LOWER(PT) /* r2:r3 :=3D table map of xen_fixmap= */ - ldr r4, =3DFIXMAP_ADDR(0) - mov r4, r4, lsr #(SECOND_SHIFT - 3) /* r4 :=3D 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= =3D1 /* Ensure any page table updates made above have occurred. */ dsb nshst =20 --=20 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel From nobody Fri May 10 17:06:59 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1568744071; cv=none; d=zoho.com; s=zohoarc; b=cI7UnjOe/ykh6vB1XFXN3XECfrjblOgTnf2nXg7WBEdboPBIQOsApm7lAnimkjQyPDJgIFaJHX39N4yVGAox9Go3jzPUdFlqk3vwq5jMb0rbCP+FJwZ8HkaCVCobrcRD52SCqheJyb/ngx0H566LS030tzhG3Yg5RZPZu6kMBSo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568744071; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=RIgDfoF5hEK5qLSlcIhWq4gZyKv3WBjYzGYRAt4N7E8=; b=ajXQ1L/j5MHc7UgaP9vm+Y5kWxfkj1Ijcr+oKSy832SWwYeOf9JMksRmtQov6gbmXGo4WbWaqWRJj+RvaqAwbywfco5KMP2JHa9EU1PHrVvg9MNmjMpI+JejV4AeN1MNMEbqvf6FoOkLFg8hL2rJhHWLJ98oXFso8DLoLCc51cM= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1568744070974272.8434822546807; Tue, 17 Sep 2019 11:14:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyc-0008NG-1H; Tue, 17 Sep 2019 18:13:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAHyb-0008MW-4p for xen-devel@lists.xenproject.org; Tue, 17 Sep 2019 18:13:21 +0000 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id c8186948-d976-11e9-b76c-bc764e2007e4; 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 A5B931650; Tue, 17 Sep 2019 11:12:59 -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 000013F67D; Tue, 17 Sep 2019 11:12:58 -0700 (PDT) X-Inumbo-ID: c8186948-d976-11e9-b76c-bc764e2007e4 From: Julien Grall To: xen-devel@lists.xenproject.org Date: Tue, 17 Sep 2019 19:12:44 +0100 Message-Id: <20190917181244.30027-9-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 8/8] xen/arm32: head: Use a page mapping for the 1:1 mapping in create_page_tables() 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" At the moment the function create_page_tables() will use 1GB/2MB mapping for the identity mapping. As we don't know what is present before and after Xen in memory, we may end up to map device/reserved-memory with cacheable memory. This may result to mismatched attributes as other users may access the same region differently. To prevent any issues, we should only map the strict minimum in the 1:1 mapping. A check in xen.lds.S already guarantees anything necessary for turning on the MMU fits in a page (at the moment 4K). As only one page will be mapped for the 1:1 mapping, it is necessary to pre-allocate a page for the 3rd level table. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v4: - Use XEN_{FIRST, SECOND}_SLOT rather than hardcoded value - Don't pre-link the page-tables for the 1:1 mapping Changes in v3: - Patch added --- xen/arch/arm/arm32/head.S | 121 +++++++++++++++++++-----------------------= ---- xen/arch/arm/mm.c | 2 +- 2 files changed, 50 insertions(+), 73 deletions(-) diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S index 175f0c9760..7b5109db26 100644 --- a/xen/arch/arm/arm32/head.S +++ b/xen/arch/arm/arm32/head.S @@ -447,73 +447,13 @@ ENDPROC(cpu_init) * r6 : Identity map in place */ create_page_tables: - /* - * If Xen is loaded at exactly XEN_VIRT_START then we don't - * need an additional 1:1 mapping, the virtual mapping will - * suffice. - */ - cmp r9, #XEN_VIRT_START - moveq r6, #1 /* r6 :=3D identity map now in place = */ - movne r6, #0 /* r6 :=3D identity map not yet in pl= ace */ - - ldr r4, =3Dboot_pgtable - add r4, r4, r10 /* r4 :=3D paddr (boot_pagetable) */ - - /* Setup boot_pgtable: */ - ldr r1, =3Dboot_second - add r1, r1, r10 /* r1 :=3D paddr (boot_second) */ - - /* ... map boot_second in boot_pgtable[0] */ - orr r2, r1, #PT_UPPER(PT) /* r2:r3 :=3D table map of boot_secon= d */ - orr r2, r2, #PT_LOWER(PT) /* (+ rights for linear PT) */ - mov r3, #0x0 - strd r2, r3, [r4, #0] /* Map it in slot 0 */ - - /* ... map of paddr(start) in boot_pgtable */ - lsrs r1, r9, #FIRST_SHIFT /* Offset of base paddr in boot_pgtab= le */ - beq 1f /* If it is in slot 0 then map in boo= t_second - * later on */ - lsl r2, r1, #FIRST_SHIFT /* Base address for 1GB mapping */ - orr r2, r2, #PT_UPPER(MEM) /* r2:r3 :=3D section map */ - orr r2, r2, #PT_LOWER(MEM) - lsl r1, r1, #3 /* r1 :=3D Slot offset */ - mov r3, #0x0 - strd r2, r3, [r4, r1] /* Mapping of paddr(start) */ - mov r6, #1 /* r6 :=3D identity map now in place = */ - -1: /* Setup boot_second: */ - ldr r4, =3Dboot_second - add r4, r4, r10 /* r4 :=3D paddr (boot_second) */ - - ldr r1, =3Dboot_third - add r1, r1, r10 /* r1 :=3D paddr (boot_third) */ - - /* ... map boot_third in boot_second[1] */ - orr r2, r1, #PT_UPPER(PT) /* r2:r3 :=3D table map of boot_third= */ - orr r2, r2, #PT_LOWER(PT) /* (+ rights for linear PT) */ - mov r3, #0x0 - strd r2, r3, [r4, #8] /* Map it in slot 1 */ - - /* ... map of paddr(start) in boot_second */ - cmp r6, #1 /* r6 is set if already created */ - beq 1f - lsr r2, r9, #SECOND_SHIFT /* Offset of base paddr in boot_secon= d */ - ldr r3, =3DLPAE_ENTRY_MASK - and r1, r2, r3 - cmp r1, #1 - beq virtphys_clash /* It's in slot 1, which we cannot ha= ndle */ - - lsl r2, r2, #SECOND_SHIFT /* Base address for 2MB mapping */ - orr r2, r2, #PT_UPPER(MEM) /* r2:r3 :=3D section map */ - orr r2, r2, #PT_LOWER(MEM) - mov r3, #0x0 - lsl r1, r1, #3 /* r1 :=3D Slot offset */ - strd r2, r3, [r4, r1] /* Mapping of paddr(start) */ - mov r6, #1 /* r6 :=3D identity map now in place = */ + /* Prepare the page-tables for mapping Xen */ + ldr r0, =3DXEN_VIRT_START + create_table_entry boot_pgtable, boot_second, r0, FIRST_SHIFT + create_table_entry boot_second, boot_third, r0, SECOND_SHIFT =20 /* Setup boot_third: */ -1: ldr r4, =3Dboot_third - add r4, r4, r10 /* r4 :=3D paddr (boot_third) */ + adr_l r4, boot_third, mmu=3D0 =20 lsr r2, r9, #THIRD_SHIFT /* Base address for 4K mapping */ lsl r2, r2, #THIRD_SHIFT @@ -530,16 +470,53 @@ create_page_tables: blo 1b =20 /* - * Defer fixmap and dtb mapping until after paging enabled, to - * avoid them clashing with the 1:1 mapping. + * If Xen is loaded at exactly XEN_VIRT_START then we don't + * need an additional 1:1 mapping, the virtual mapping will + * suffice. */ + cmp r9, #XEN_VIRT_START + moveq pc, lr =20 - /* boot pagetable setup complete */ +1: + /* + * Setup the 1:1 mapping so we can turn the MMU on. Note that + * only the first page of Xen will be part of the 1:1 mapping. + */ + + /* + * Find the first slot used. If the slot is not XEN_FIRST_SLOT, + * then the 1:1 mapping will use its own set of page-tables from + * the second level. + */ + lsr r1, r9, #FIRST_SHIFT + mov_w r0, LPAE_ENTRY_MASK + and r1, r1, r0 /* r1 :=3D first slot */ + cmp r1, #XEN_FIRST_SLOT + beq 1f + create_table_entry boot_pgtable, boot_second_id, r9, FIRST_SHIFT + b link_from_second_id + +1: + /* + * Find the second slot used. If the slot is XEN_SECOND_SLOT, then= the + * 1:1 mapping will use its own set of page-tables from the + * third level. For slot XEN_SECOND_SLOT, Xen is not yet able to h= andle + * it. + */ + lsr r1, r9, #SECOND_SHIFT + mov_w r0, LPAE_ENTRY_MASK + and r1, r1, r0 /* r1 :=3D second slot */ + cmp r1, #XEN_SECOND_SLOT + beq virtphys_clash + create_table_entry boot_second, boot_third_id, r9, SECOND_SHIFT + b link_from_third_id + +link_from_second_id: + create_table_entry boot_second_id, boot_third_id, r9, SECOND_SHIFT +link_from_third_id: + create_mapping_entry boot_third_id, r9, r9 + mov pc, lr =20 - cmp r6, #1 /* Did we manage to create an identity= mapping ? */ - moveq pc, lr - PRINT("Unable to build boot page tables - Failed to identity map X= en.\r\n") - b fail virtphys_clash: /* Identity map clashes with boot_third, which we cannot handle ye= t */ PRINT("- Unable to build boot page tables - virt and phys addresse= s clash. -\r\n") diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 72ffea7472..9e0fdc39f9 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -105,9 +105,9 @@ DEFINE_BOOT_PAGE_TABLE(boot_pgtable); #ifdef CONFIG_ARM_64 DEFINE_BOOT_PAGE_TABLE(boot_first); DEFINE_BOOT_PAGE_TABLE(boot_first_id); +#endif DEFINE_BOOT_PAGE_TABLE(boot_second_id); DEFINE_BOOT_PAGE_TABLE(boot_third_id); -#endif DEFINE_BOOT_PAGE_TABLE(boot_second); DEFINE_BOOT_PAGE_TABLE(boot_third); =20 --=20 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel