Hi Julien, > -----Original Message----- > From: Julien Grall <jul...@xen.org> > Sent: Tuesday, January 31, 2023 5:28 PM > To: Penny Zheng <penny.zh...@arm.com>; xen-devel@lists.xenproject.org; > Wei Chen <wei.c...@arm.com>; Stefano Stabellini > <sstabell...@kernel.org>; Bertrand Marquis <bertrand.marq...@arm.com>; > ayan.kumar.hal...@xilinx.com > Cc: Volodymyr Babchuk <volodymyr_babc...@epam.com> > 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 <jul...@xen.org> > >> Sent: Monday, January 30, 2023 5:40 PM > >> To: Penny Zheng <penny.zh...@arm.com>; xen- > de...@lists.xenproject.org > >> Cc: Wei Chen <wei.c...@arm.com>; Stefano Stabellini > >> <sstabell...@kernel.org>; Bertrand Marquis > >> <bertrand.marq...@arm.com>; Volodymyr Babchuk > >> <volodymyr_babc...@epam.com> > >> 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
