Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Julien Grall <julien.grall@xxxxxxx>]

On 03/30/2017 09:17 PM, Volodymyr Babchuk wrote:
> Hi Julien,
Hi Volodymyr,

> On 30 March 2017 at 22:57, Julien Grall <julien.grall@xxxxxxx> wrote:
> > Hi Volodymyr
> >
> > On 30/03/2017 20:19, Volodymyr Babchuk wrote:
> > > On 30 March 2017 at 21:52, Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > 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.Hi
>
> 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...
I cannot see why stage-1 page table cannot be disabled.

> 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.
Even if you disable stage-2 translation, you still have to program 
VTTBR_EL2.VMID because, from my understanding the TLBs will still be 
tagged with the VMID (see the note in page D4-1823 in ARM DDI 
0487A.k_iss10775).
If you keep the VMID of the guest, you would need to flush the TLBs at 
every context switch to avoid TLB conflict.
To prevent that, you would need a specific VMID for the EL0 app, and 
therefore save/restore a part of the p21m context everytime.
The benefits of using stage-2 page table, is you can leverage the p2m 
code rather than creating another version to handle stage-1.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel