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

[Penny Zheng <Penny.Zheng@xxxxxxx>]

Hi Julien,

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Sent: Thursday, February 2, 2023 2:57 AM
> To: Penny Zheng <Penny.Zheng@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx;
> Wei Chen <Wei.Chen@xxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; Bertrand Marquis <Bertrand.Marquis@xxxxxxx>;
> ayan.kumar.halder@xxxxxxxxxx
> Cc: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
> Subject: Re: [PATCH v2 11/40] xen/mpu: build up start-of-day Xen MPU
> memory region map
> 
> Hi Penny,
> 
> On 01/02/2023 05:39, Penny Zheng wrote:
> >>> If we are adding MPU regions in sequence as you suggested, while
> >>> using bitmap at the same time to record used entry.
> >>> TBH, this is how I designed at the very beginning internally. We
> >>> found that if we don't do reorg late-boot to keep fixed in front and
> >>> switching ones after, each time when we do vcpu context switch, not
> >>> only we need to hunt down switching ones to disable, while we add
> >>> new switch-in regions, using bitmap to find free entry is saying
> >>> that the
> >> process is unpredictable. Uncertainty is what we want to avoid in
> >> Armv8-R architecture.
> >>
> >> I don't understand why it would be unpredictable. For a given
> >> combination of platform/device-tree, the bitmap will always look the
> >> same. So the number of cycles/instructions will always be the same.
> >>
> >
> > In boot-time, it will be always the same. But if we still use bitmap
> > to find free entry(for switching MPU regions) on runtime, hmmm, I
> > thought this part will be unpredictable.
> 
> I know this point is now moot as we agreed on not using a bitmap but I
> wanted to answer on the unpredictability part.
> 
> It depends on whether you decide to allocate more entry at runtime. My
> assumption is you won't and therefore the the time to walk the bitmap will
> always be consistent.
> 

In MPU, we don't have something like vttbr_el2 in MMU, to store stage 2
EL1/EL0 translation table. Xen stage 1 EL2 mapping and stage 2 EL1/EL0
mapping are both sharing one table.
So when context switching into different guest, the current design is to disable
DOM1's guest RAM mapping firstly, then enable DOM2's guest RAM mapping,
to ensure isolation and safety.

> Cheers,
> 
> --
> Julien Grall