Lets make it clear - there must be one translation table for EL0 apps... On Mar 30, 2017 23:18, Volodymyr Babchuk wrote: Hi Julien, On 30 March 2017 at 22:57, Julien Grall wrote: > Hi Volodymyr > > On 30/03/2017 20:19, Volodymyr Babchuk wrote: >> >> On 30 March 2017 at 21:52, Stefano Stabellini >> wrote: >>> >>> On Thu, 30 Mar 2017, Volodymyr Babchuk wrote: >> >> And yes, my profiler shows that there are ways to further decrease >> latency. Most obvious way is to get rid of 2nd stage translation and >> thus eliminate p2m code from the call chain. Currently hypervisor >> spends 20% of time in spinlocks code and about ~10-15% in p2m. So >> there definitely are areas to improve :) > > > Correct me if I am wrong. You are suggesting to remove stage-2 MMU > translation, right? If so, what are the benefits to have some Xen code > running at EL0? Because that will be loadable code :) Also, this will provide some degree of isolation as this code will communicate with Xen only via SVCs. Look, we need two stages in the first place because conventional guest wants to control own MMU. But Xen native app (lets call it in this way) should not control MMU. In my hack I had to create stage-1 table with 1:1 mapping to make things work. Actually.... it just came to me that I can try to disable stage 1 MMU and leave only stage 2. Not sure if it is possible, need to check TRM... But, anyways, my initial idea was to disable second stage MMU (drop VM bit in HCR_EL2) and program only TTBR0_EL1 with friends. With this approach there will be no need to save/restore p2m context when I switch from guest context to app context and back. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babchuk@gmail.com