Hi, Julien > -----Original Message----- > From: Julien Grall <[email protected]> > Sent: Thursday, February 2, 2023 6:58 PM > To: Penny Zheng <[email protected]>; [email protected]; > Wei Chen <[email protected]>; Stefano Stabellini > <[email protected]>; Bertrand Marquis <[email protected]>; > [email protected] > Cc: Volodymyr Babchuk <[email protected]> > 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 <[email protected]> > >> Sent: Thursday, February 2, 2023 2:57 AM > >> To: Penny Zheng <[email protected]>; > >> [email protected]; Wei Chen <[email protected]>; > Stefano > >> Stabellini <[email protected]>; Bertrand Marquis > >> <[email protected]>; [email protected] > >> Cc: Volodymyr Babchuk <[email protected]> > >> 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
