Hi Julien > -----Original Message----- > From: Julien Grall <jul...@xen.org> > Sent: Monday, November 7, 2022 5:30 PM > To: Penny Zheng <penny.zh...@arm.com>; Wei Chen > <wei.c...@arm.com>; xen-devel@lists.xenproject.org > Cc: nd <n...@arm.com>; Stefano Stabellini <sstabell...@kernel.org>; Bertrand > Marquis <bertrand.marq...@arm.com>; Volodymyr Babchuk > <volodymyr_babc...@epam.com> > Subject: Re: [PATCH v6 09/11] xen/arm64: create boot-time MPU protection > regions > > On 07/11/2022 06:59, Penny Zheng wrote: > > Hi Julien > > Hi Penny, > > >>> + > >>> +/* > >>> + * In boot stage, we will use 1 MPU region: > >>> + * Region#0: Normal memory for Xen text + data + bss (2MB) */ > >> > >> Are we only going to modify the MPU in head.S? If not, then I would > >> define the layout in config_mpu.h so there are a single point where > >> you can read how this works. > >> > > > > We will remap Xen in C codes in setup_mm(). > > The whole strategy is aligned with MMU: a very simple setup(map xen > > with the maximum size, 2M) at start-of-the-day, and a fit map in > > setup_mm. > > The strategy we are using for the MMU is completely broken (not compliant > with the Arm Arm) and unnecessary. My long term goal is to actually remove > the switch_ttbr() and most of setup_pagetables() for all setup but cache > coloring. This means the concept of boot pages will not exist anymore. > > For the MPU, we should aim to do better than what was done for the MMU. > Right now, I see no argument for switching MPUs table. I am only seen > argument against it because you need to disable the cache and is quite > fragile. >
> [...] > > >>> + > >>> + ldr x2, =XEN_START_ADDRESS > >>> + mov x3, #(XEN_START_MEM_SIZE - 1) > >> > >> XEN_START_MEM_SIZE is the maximum size of Xen. IOW, Xen may be > >> smaller and you will map memory that may not be part of Xen. > >> Therefore, you likely want to compute the real size to avoid mapping > >> too much. > >> > > > > Later, in setup_mm we will map XEN components by components, such as, > > one MPU memory region for read-only-executable text section, one MPU > > memory region for read-only data section, etc, etc. > > So in there, XEN will be mapped fitly. > > But what prevents you to do this now? > > > > > IMHO, the mapping in compiler with maximum size of Xen is also what > > MMU does. > > Which is broken because we don't know what located after Xen binary. > This could be reserved RAM, device which may requires non-caching > attribute. Mapping those regions with caching attributes is going to break. > Understood! Then I will map Xen components by components in the compile time, then later the first MPU/Cache disabled will be eliminated, I guess. > > Cheers, > > [1] 20221022150422.17707-1-jul...@xen.org > > -- > Julien Grall
