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: Tuesday, January 31, 2023 5:28 PM
> 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
> 
> 
> 
> On 31/01/2023 04:11, Penny Zheng wrote:
> > Hi Julien
> >
> >> -----Original Message-----
> >> From: Julien Grall <julien@xxxxxxx>
> >> Sent: Monday, January 30, 2023 5:40 PM
> >> To: Penny Zheng <Penny.Zheng@xxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> >> Cc: Wei Chen <Wei.Chen@xxxxxxx>; Stefano Stabellini
> >> <sstabellini@xxxxxxxxxx>; Bertrand Marquis
> >> <Bertrand.Marquis@xxxxxxx>; 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,
> >>
[...]
> >>
> >> I would suggest to investigate the cost of "hunting down each section".
> >> Depending on the result, we can discuss what the best approach.
> >>
> >
> > Correct me if I'm wrong, the complicated things in assembly you are
> > worried about is that we couldn't define the index for initial sections, no
> hardcoded to keep simple.
> 
> Correct.
> 
> > And function write_pr, ik, is really a big chunk of codes, however the
> > logic is simple there, just a bunch of "switch-cases".
> 
> I agree that write_pr() is a bunch of switch-cases. But there are a lot of
> duplication in it and the interface to use it is, IMHO, not intuitive.
> 
> >
> > 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.

> This is not very different from the case where you split the MPU in two
> because
> 
> >
> > Hmmm, TBH, I really really like your suggestion to put
> > boot-only/switching regions into higher slot. It really saved a lot
> > trouble in late-init reorg and also avoids disabling MPU at the same
> > time. The split is a simple and easy-to-understand construction compared
> with bitmap too.
> 
> I would like to propose another split. I will reply to that in the thread 
> where
> you provided the MPU layout.
> 
> Cheers,
> 
> --
> Julien Grall