mbox series

[v1,repost,0/4] xen/arm64: Rework the MMU-off code (idmap) so it is self-contained

Message ID 20240116143709.86584-1-julien@xen.org (mailing list archive)
Headers show
Series xen/arm64: Rework the MMU-off code (idmap) so it is self-contained | expand

Message

Julien Grall Jan. 16, 2024, 2:37 p.m. UTC
From: Julien Grall <jgrall@amazon.com>

Hi all,

Right now, the MMU-off code will access may access data that are either
in .rodata or .data. With the enablement of cache coloring, Xen may
not be physcally contiguous anymore when secondary CPUs are brought up.

There are multiple way to solve this problem. The first is to keep
a copy of Xen physically contiguous in memory. The downside is this
means we are using up to 8MB (maximum size of Xen) when only a few
KBs is necessary.

This series is reworking the logic so all the MMU-off code is now
self-contained for secondary boot CPUs on arm64.

On arm32, this is not yet possible because secondary CPUs needs to
rebuild boot page-tables.

Cheers,

Julien Grall (4):
  arm/mmu: Move init_ttbr to a new section .data.idmap
  arm/smpboot: Move smp_up_cpu to a new section .data.idmap
  xen/arm64: head: Use PRINT_ID() for secondary CPU MMU-off boot code
  [DO NOT COMMIT] xen/arm: Create a trampoline for secondary boot CPUs

 xen/arch/arm/arm64/head.S               | 14 +++----
 xen/arch/arm/arm64/mmu/head.S           |  2 +-
 xen/arch/arm/arm64/mmu/mm.c             |  7 ++++
 xen/arch/arm/include/asm/arm64/macros.h |  9 +++--
 xen/arch/arm/mmu/smpboot.c              | 36 +++++++++++++++---
 xen/arch/arm/psci.c                     |  5 ++-
 xen/arch/arm/smpboot.c                  | 49 ++++++++++++++++++++++---
 xen/arch/arm/xen.lds.S                  |  1 +
 8 files changed, 101 insertions(+), 22 deletions(-)

Comments

Julien Grall Jan. 25, 2024, 6:38 p.m. UTC | #1
Hi,

On 16/01/2024 14:37, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Hi all,
> 
> Right now, the MMU-off code will access may access data that are either
> in .rodata or .data. With the enablement of cache coloring, Xen may
> not be physcally contiguous anymore when secondary CPUs are brought up.
> 
> There are multiple way to solve this problem. The first is to keep
> a copy of Xen physically contiguous in memory. The downside is this
> means we are using up to 8MB (maximum size of Xen) when only a few
> KBs is necessary.
> 
> This series is reworking the logic so all the MMU-off code is now
> self-contained for secondary boot CPUs on arm64.
> 
> On arm32, this is not yet possible because secondary CPUs needs to
> rebuild boot page-tables.
> 
> Cheers,
> 
> Julien Grall (4):
>    arm/mmu: Move init_ttbr to a new section .data.idmap
>    arm/smpboot: Move smp_up_cpu to a new section .data.idmap
>    xen/arm64: head: Use PRINT_ID() for secondary CPU MMU-off boot code

The first 3 patches are now committed.

Cheers,