[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.