From patchwork Fri Jan 27 19:55:03 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julien Grall X-Patchwork-Id: 13119308 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 35268C54EAA for ; Fri, 27 Jan 2023 19:55:36 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.485921.753368 (Exim 4.92) (envelope-from ) id 1pLUob-0008Hh-TV; Fri, 27 Jan 2023 19:55:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 485921.753368; Fri, 27 Jan 2023 19:55:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pLUob-0008Ha-QQ; Fri, 27 Jan 2023 19:55:13 +0000 Received: by outflank-mailman (input) for mailman id 485921; Fri, 27 Jan 2023 19:55:12 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pLUoa-0008HU-Sk for xen-devel@lists.xenproject.org; Fri, 27 Jan 2023 19:55:12 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pLUoa-00077l-Ex; Fri, 27 Jan 2023 19:55:12 +0000 Received: from 54-240-197-232.amazon.com ([54.240.197.232] helo=dev-dsk-jgrall-1b-035652ec.eu-west-1.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pLUoa-0002YX-54; Fri, 27 Jan 2023 19:55:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date: Subject:Cc:To:From; bh=zl61osytHpssWg6N5x3XEIa5GQM4XDkKGDQRne3hbt0=; b=JHVV/J SBLTjDbXLw5LvH6y8CzusDSZ1zct6hMWPta6Bh8foqGNSZCa+kQOIeGUebliqpvWrEQsqAvobr7se hM2neWMSlddzHVifVHSGGYiwZ2dCxtEr+MwmdwlKpkdp+ZvNcOHpPUpEkG/iI48s7MrDcyP+i9T/k wRKxEfvKIVc=; From: Julien Grall To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, michal.orzel@amd.com, Julien Grall , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH v5 0/5] xen/arm: Don't switch TTBR while the MMU is on Date: Fri, 27 Jan 2023 19:55:03 +0000 Message-Id: <20230127195508.2786-1-julien@xen.org> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 From: Julien Grall Hi all, Currently, Xen on Arm will switch TTBR whilst the MMU is on. This is similar to replacing existing mappings with new ones. So we need to follow a break-before-make sequence. When switching the TTBR, we need to temporarily disable the MMU before updating the TTBR. This means the page-tables must contain an identity mapping. The current memory layout is not very flexible and has an higher chance to clash with the identity mapping. On Arm64, we have plenty of unused virtual address space Therefore, we can simply reshuffle the layout to leave the first part of the virtual address space empty. On Arm32, the virtual address space is already quite full. Even if we find space, it would be necessary to have a dynamic layout. So a different approach will be necessary. The chosen one is to have a temporary mapping that will be used to jumped from the ID mapping to the runtime mapping (or vice versa). The temporary mapping will be overlapping with the domheap area as it should not be used when switching on/off the MMU. The Arm32 part is not yet addressed and will be handled in a follow-up series. After this series, most of Xen page-table code should be compliant with the Arm Arm. The last two issues I am aware of are: - domheap: Mappings are replaced without using the Break-Before-Make approach. - The cache is not cleaned/invalidated when updating the page-tables with Data cache off (like during early boot). The long term plan is to get rid of boot_* page tables and then directly use the runtime pages. This means for coloring, we will need to build the pages in the relocated Xen rather than the current Xen. For convience, I pushed a branch with everything applied: https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git branch boot-pt-rework-v5 Cheers, Julien Grall (5): xen/arm32: head: Widen the use of the temporary mapping xen/arm64: Rework the memory layout xen/arm64: mm: Introduce helpers to prepare/enable/disable the identity mapping xen/arm64: mm: Rework switch_ttbr() xen/arm64: smpboot: Directly switch to the runtime page-tables xen/arch/arm/arm32/head.S | 85 +++------------ xen/arch/arm/arm32/smpboot.c | 4 + xen/arch/arm/arm64/Makefile | 1 + xen/arch/arm/arm64/head.S | 82 +++++++------- xen/arch/arm/arm64/mm.c | 161 ++++++++++++++++++++++++++++ xen/arch/arm/arm64/smpboot.c | 15 ++- xen/arch/arm/include/asm/arm32/mm.h | 4 + xen/arch/arm/include/asm/arm64/mm.h | 13 +++ xen/arch/arm/include/asm/config.h | 34 ++++-- xen/arch/arm/include/asm/mm.h | 2 + xen/arch/arm/include/asm/setup.h | 11 ++ xen/arch/arm/include/asm/smp.h | 1 + xen/arch/arm/mm.c | 19 ++-- xen/arch/arm/smpboot.c | 1 + 14 files changed, 305 insertions(+), 128 deletions(-) create mode 100644 xen/arch/arm/arm64/mm.c