Re: [PATCH v2 11/40] xen/mpu: build up start-of-day Xen MPU memory region map

[Julien Grall <julien@xxxxxxx>]

Hi Penny,

On 30/01/2023 05:45, Penny Zheng wrote:
>   There are three types of MPU regions during boot-time:
> 1. Fixed MPU region
> Regions like Xen text section, Xen heap section, etc.
> 2. Boot-only MPU region
> Regions like Xen init sections, etc. It will be removed at the end of booting.
> 3.   Regions need switching in/out during vcpu context switch
> Region like system device memory map.
> For example, for FVP_BaseR_AEMv8R, we have [0x80000000, 0xfffff000) as
> the whole system device memory map for Xen(idle vcpu) in EL2,  when
> context switching to guest vcpu, it shall be replaced with guest-specific
> device mapping, like vgic, vpl011, passthrough device, etc.
>
> We don't have two mappings for different stage translations in MPU, like we had 
> in MMU.
> Xen stage 1 EL2 mapping and stage 2 mapping are both sharing one MPU memory 
> mapping(xen_mpumap)
> So to save the trouble of hunting down each switching regions in time-sensitive 
> context switch, we
> must re-order xen_mpumap to keep fixed regions in the front, and switching ones 
> in the heels of them.
From my understanding, hunting down each switching regions would be a 
matter to loop over a bitmap. There will be a slight increase in the 
number of instructions executed, but I don't believe it will be noticeable.
> In Patch Serie v1, I was adding MPU regions in sequence,  and I introduced a 
> set of bitmaps to record the location of
> same type regions. At the end of booting, I need to *disable* MPU to do the 
> reshuffling, as I can't
> move regions like xen heap while MPU on.
>
> And we discussed that it is too risky to disable MPU, and you suggested [1]
> "
> > You should not need any reorg if you map the boot-only section towards in
> > the higher slot index (or just after the fixed ones).
> "
Right, looking at the new code. I realize that this was probably a bad 
idea because we are adding complexity in the assembly code.
> Maybe in assembly, we know exactly how many fixed regions are, boot-only 
> regions are, but in C codes, we parse FDT
> to get static configuration, like we don't know how many fixed regions for xen 
> static heap is enough.
> Approximation is not suggested in MPU system with limited MPU regions, some 
> platform may only have 16 MPU regions,
> IMHO, it is not worthy wasting in approximation.
I haven't suggested to use approximation anywhere here. I will answer 
about the limited number of entries in the other thread.
> So I take the suggestion of putting regions in the higher slot index. Putting 
> fixed regions in the front, and putting
> boot-only and switching ones at tail. Then, at the end of booting, when we 
> reorg the mpu mapping, we remove
> all boot-only regions, and for switching ones, we disable-relocate(after fixed 
> ones)-enable them. Specific codes in [2].
From this discussion, it feels to me that you are trying to make the 
code more complicated just to keep the split and save a few cycles (see 
above).
I would suggest to investigate the cost of "hunting down each section". 
Depending on the result, we can discuss what the best approach.
Cheers,

--
Julien Grall