https://ziyang.eecs.umich.edu/esds/papers/hwang-xen.pdf
ARM Linux kernel is implemented assuming that it runs at supervisor mode and all register contexts are supervisor mode context.
VMM mode is entered when exceptions such as interrupt, fault, abort, and software interrupt occurs. On entry to VMM mode, ARM CPU’s SPSR (Saved Program Status Register) is saved in the VSPSR (virtual SPSR) which will be restored later when guest OS returns from exception. Stack pointer register is also saved in VSP register for later restoration.
Xen invokes upcall to deliver exceptions to kernel mode as virtual exception events. On upcall, Xen puts the VSPSR information on the kernel’s stack so that kernel can get last running virtual processor mode. The upcall mechanism corresponds to hardware level exception handling that makes CPU to jump into exception vector table.
Since guest OS should run in user mode, all sensitive instructions contained in guest OS should be placed with proper hypercalls.
Kernel Hypervisor
Syscall <----------> Hypercall Xen hypervisor does not require cache flushing on switching between virtual priviledge modes inside the same virtual machine. The page table of a process has non-overlapping page mappings for the process memory, OS kernel memory, and VMM memory.
ARM provides eight lockdown TLB entries which are not invalidated though TLB flush occurs. We use two lockdown TLB entries to hold mappings for Xen memory area. This reduces VMM overheads slightly by keeping TLB entries always.
Since paravirtualized guest OSes should run in user mode, they are not allowed to manipulate MMU but instead they can invoke hypercalls to control MMU, which is then validated by Xen on ARM.
Any attempt to map/unmap/read/write other domain’s memory page is prohibited by VMM. Though a domain is compromised by a malicious software, it cannot attack other domain as far as VMM is not compromised. Other research colleagues independently worked on making Xen on ARM secure. https://ieeexplore.ieee.org/document/4446361