Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

[Julien Grall <julien.grall@xxxxxxx>]

On 05/10/2017 06:37 PM, Volodymyr Babchuk wrote:
> Hi Julien,
Hi Volodymyr,

> Returning back to Native apps, I think we can make ctx switch even
> faster by dropping p2m code. Imagine that we already created stage 1
> MMU for native application. Then to switch to app it we need only:
>
> 1. Enable TGE bit in HCR
> 2. Disable VM bit in HCR
> 3. Save/Program EL1_TTBR and friends
> 3.5 (optionally) save/restore FPU state
> 4. Save/Restore general purpose registers + SP + CSR + PC to jump to
> an app in EL0 state.
>
> This can be done in "real" vcpu or in idle vcpu context. No differences there.
>
> Exception handling in hypervisor would became tricky because of vcpu
> absence for native app. Current implementation of entry.S always says
> general purpose registers to a vcpu structure. Basically, we should
> teach entry.S and traps.c about native apps.
> Am I missing something?
HCR_EL2.VM is allowed to be cached in the TLBs so for correctness you 
have to flush the TLBs everytime you change this bit (see D4.8.3 in ARM 
DDI 0487A.k_iss10775).
Furthermore, as I mentioned earlier (see [1]) there are dependencies on 
the VMID even when stage-2 is disabled (see D4-1823 in ARM DDI 
0487A.k_iss10775) so you have to program correctly VTTBR_EL2.VMID. This 
also means that if you use a different EL0 app, you have to ther use a 
different VMID or flush the TLBs.
Bottom line, if you don't use stage-2 page table you have to flush the 
TLBs. Likely this will have an higher impact on the platform than using 
stage-2 page table.
Virtual memory is quite tricky, someone needs to look at the ARM ARM and 
check all the behaviors when disabling either stage-1 or stage-2. There 
are memory attribute implications that may make tricky to move an EL0 
app between pCPU.
CC Steve on the discussion to get more feedback. We are trying to 
disable completely EL1.
Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2017-03/msg04374.html

--
Julien Grall

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