xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: xen-devel@lists.xenproject.org
Cc: marco.solieri@minervasys.tech, lucmiccio@gmail.com,
	carlo.nonato@minervasys.tech, Julien Grall <jgrall@amazon.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [RFC v2 00/12] xen/arm: Don't switch TTBR while the MMU is on
Date: Sat, 22 Oct 2022 16:04:10 +0100	[thread overview]
Message-ID: <20221022150422.17707-1-julien@xen.org> (raw)

From: Julien Grall <jgrall@amazon.com>

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 temporary 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 in this version. The series is
sent as an early RFC to gather some feedback on the approach.

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-v2

Cheers,

Julien Grall (12):
  xen/arm: Clean-up the memory layout
  xen/arm32: head: Jump to the runtime mapping in enable_mmu()
  xen/arm32: head: Introduce an helper to flush the TLBs
  xen/arm32: head: Remove restriction where to load Xen
  xen/arm32: head: Widen the use of the temporary mapping
  xen/arm: Enable use of dump_pt_walk() early during boot
  xen/arm64: Rework the memory layout
  xen/arm: mm: Allow xen_pt_update() to work with the current root table
  xen/arm: mm: Allow dump_hyp_walk() to work on the current root table
  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           | 253 ++++++++++++++++++----------
 xen/arch/arm/arm32/smpboot.c        |   4 +
 xen/arch/arm/arm64/Makefile         |   1 +
 xen/arch/arm/arm64/head.S           |  86 +++++-----
 xen/arch/arm/arm64/mm.c             | 160 ++++++++++++++++++
 xen/arch/arm/arm64/smpboot.c        |  15 +-
 xen/arch/arm/domain_page.c          |   9 +
 xen/arch/arm/include/asm/arm32/mm.h |   4 +
 xen/arch/arm/include/asm/arm64/mm.h |  12 ++
 xen/arch/arm/include/asm/config.h   |  63 +++++--
 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                   | 105 +++++++-----
 xen/arch/arm/smpboot.c              |   1 +
 15 files changed, 536 insertions(+), 191 deletions(-)
 create mode 100644 xen/arch/arm/arm64/mm.c

-- 
2.37.1



             reply	other threads:[~2022-10-22 15:04 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-22 15:04 Julien Grall [this message]
2022-10-22 15:04 ` [RFC v2 01/12] xen/arm: Clean-up the memory layout Julien Grall
2022-10-24 14:59   ` Luca Fancellu
2022-10-25  9:21   ` Michal Orzel
2022-10-25 10:31     ` Julien Grall
2022-10-25 10:36       ` Michal Orzel
2022-10-25 20:07         ` Julien Grall
2022-10-22 15:04 ` [RFC v2 02/12] xen/arm32: head: Jump to the runtime mapping in enable_mmu() Julien Grall
2022-10-25  9:45   ` Michal Orzel
2022-10-25 10:05     ` Julien Grall
2022-10-22 15:04 ` [RFC v2 03/12] xen/arm32: head: Introduce an helper to flush the TLBs Julien Grall
2022-10-25  9:53   ` Michal Orzel
2022-10-25 10:41     ` Julien Grall
2022-10-22 15:04 ` [RFC v2 04/12] xen/arm32: head: Remove restriction where to load Xen Julien Grall
2022-10-25 11:56   ` Luca Fancellu
2022-11-17 20:18     ` Julien Grall
2022-11-25 15:50       ` Luca Fancellu
2022-12-06 18:29         ` Julien Grall
2022-10-22 15:04 ` [RFC v2 05/12] xen/arm32: head: Widen the use of the temporary mapping Julien Grall
2022-10-22 15:04 ` [RFC v2 06/12] xen/arm: Enable use of dump_pt_walk() early during boot Julien Grall
2022-10-22 15:04 ` [RFC v2 07/12] xen/arm64: Rework the memory layout Julien Grall
2022-10-22 15:04 ` [RFC v2 08/12] xen/arm: mm: Allow xen_pt_update() to work with the current root table Julien Grall
2022-10-22 15:04 ` [RFC v2 09/12] xen/arm: mm: Allow dump_hyp_walk() to work on " Julien Grall
2022-10-22 15:04 ` [RFC v2 10/12] xen/arm64: mm: Introduce helpers to prepare/enable/disable the identity mapping Julien Grall
2022-10-22 15:04 ` [RFC v2 11/12] xen/arm64: mm: Rework switch_ttbr() Julien Grall
2022-10-22 15:04 ` [RFC v2 12/12] xen/arm64: smpboot: Directly switch to the runtime page-tables Julien Grall
2022-10-24 15:39 ` [RFC v2 00/12] xen/arm: Don't switch TTBR while the MMU is on Xenia Ragiadakou
2022-10-24 15:46   ` 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=20221022150422.17707-1-julien@xen.org \
    --to=julien@xen.org \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=carlo.nonato@minervasys.tech \
    --cc=jgrall@amazon.com \
    --cc=lucmiccio@gmail.com \
    --cc=marco.solieri@minervasys.tech \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).