Xen Summit 2023 Design Session: R82/R52 Upstream

[Henry Wang <Henry.Wang@xxxxxxx>]

Hi all,

Below is the (merged) note take from the R82/R52 design session. Thanks Luca and
Ayan for sharing the notes taken from their side.

B: Status of current R82? Summary of the changes from last version?
P: R82 updated patches are on mailing list. A lot of change, now map
   on demand, and deleted "mpu,xxx-section" properties in device tree,
   only need to specify static heap
J: Problem is how to split and integrate the MPU code to the current
   code base
S: better to split MPU and MMU, I wouldn't mind p2m to be duplicated,
   instead of ifdefs and things like that.
J: Better to look at the whole series to have a overview of the current code.
B: We need to maintain the MPU code for a long time.
S: Keeping MMU and MPU so close together now might be not a really good idea
B: We should make sure MPU is not an Arm specific thing because RISCV also
   has MPU solutions, we need to take this into account, Do we want some MPU
   on common code?
Jan: if code to be shared by x86, arm, riscv etc, they should be common code.
A: Possibility to cut the series short?
P: The latest series out in ML already doing MMU refactoring first (the first
   22/23 patches), then introduce MPU
B: It is tricky to just see the first part without looking what is being done
   later, because one change on the first can make sense reading maybe the
   last patches.
   We are introducing a core concept in xen and finding the correct approach is 
important
   From the review point of view, we should not cut the series to parts
J: I agree.
B: The first (refactoring MMU) part is also critical for the MMU users in
   production, we need to make sure we do things right.
S: We should look at the whole series first, then iterate only the first part?
J: Yes and no...
B: Important for Ayan to look at what penny has done to avoid rework from his
   or both side. Review from Ayan as a reminder for arm32 MPU work is important.
   Is there any major code refactoring (of Penny's series) required to make it 
run on R52?
   The expectation is that the MPU code should be common between R82 and R52.
   If so, Ayan put appropriate comments in Penny's patches.
J: We need to review the whole series. This might should take some time (1-2 
full days). 
B: We are near to the release, any goal for this series?
J: MMU/MPU split to merge as the release goal would be nice. Some rework of the
   mmu is fine for 4.18, MPU won't be in for this release.
Ayan: Like linux kernel, creating topic branch is a good idea?
B & S: We had these discussions, I dont think to create topic branch for MPU is
   a good idea, but a topic branch makes sure everyone has a same view of the
   code instead of their own pieces.
B: Once Ayan does the rebase, we can have a place in gitlab to store the code
Ayan: I will point the "problematic" part from Penny's series during my rebase
   process and signal in mailing list.
B: I think penny has limited time on MPU, wei what's your input?
Wei: I've convinced internal management to include Henry in MPU
Wei: Also in current work containing 52 patches, we already split the patch 
   logically in parts which can be committed separately.
B: Will try to achieve the above goal for 4.18
J: Tell maintainers how to test MPU
S: Upstream gitlab runner might have the license issue.
B: upstream yocto (might) solved this issue?
S & Ayan: R series EL2 emulation is not possible in QEMU
Wei: Zephyr is already using FVP_BaseR in CI
B: Zephyr is not using gitlab, EULA is difficult, but it is a known issue and 
   possible to solve this
Ayan: Summary - (1) B & J & S will look the series to see if the MMU MPU split 
   is fine (2) Ayan will try to rebase and signal penny about gaps for R52
   (3) Check if the EULA license permits FVP to be used in docker.
S: 3 design questions:
 - how do we split the mmu and mpu,  Things like P2M is difficult, how to make
   p2m work
 - a lot of static inline return 0 (stubs), can we use common instead?
 - MPU is even more static than the normal dom0less, so usually for different
   platform it's a build time configuration. Having it dynamic it's not really 
   a use case, it's nice to have but it's not necessary.
B: Nobody will use MPU without recompile Xen, also we dont have bootloader for
   R series
J: why not PIE?
B & Wei: toolchain support is bad. GCC has weak support for PIE, also for
   realtime purpose PIE isn't used. Statically allocated resources are hard to 
   deal with the PIE case.
Wei: We also have discussed the PIC/PIE possiblity in 
https://lore.kernel.org/all/PAXPR08MB74206746246D1754682AA1959E999@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/t/#m77cbaf5b606901e5834e7c6fb3e30841da589d4b
 
section#3.3
J: Linux is able to do it. But we can start from things that are easy.
B: Introducing too much "dynamic" part is not good for real time.
S: Although I personally like the dynamic stuff, but most users will not use
   them.
B: You dont have firmware, booting on several platform is already a problem.
   We will investigate PIE, but not a good idea for the current stage.

We can relax the check in head.S for arm32.

Kind regards,
Henry