Hi, Julien > -----Original Message----- > From: Julien Grall <jul...@xen.org> > Sent: Thursday, February 2, 2023 6:58 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 02/02/2023 10:53, Penny Zheng wrote: > > Hi Julien, > > Hi, > > >> -----Original Message----- > >> From: Julien Grall <jul...@xen.org> > >> Sent: Thursday, February 2, 2023 2:57 AM > >> 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 > >> > >> 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. > > I understood that but I don't understand how this is related to my point > here. The entries you are replacing are always going to be the same after > boot. > > So if you have a bitmap indicate the fixed entries and you don't add more > fixed one at runtime, then it will always take the same time to walk it. >
Ah, sorry for taking so long to understand ;/. True, the fixed entries will never change after boot-time, each time when switching to guest vcpu, we always choose the same entry. > Cheers, > > -- > Julien Grall Cheers, -- Penny Zheng
