Hi Julien, > -----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. > Cheers, > > -- > Julien Grall
