Dear all,
I am interested in a scenario where I want to host two guest OSes above a bare-metal hypervisor on an ARM mobile platform. The total available memory platform is 4GB where I want to expose exclusively 2 GB of continuous RAM to each guest OS. Could you please guide me through my two below concerns:
1- in case I change the FDT (device tree) of each guest OS to reflect exclusively 2 GB of continuous memory, can I be assured that the kernel of the guest OS will only access these 2 GB, and further it is not even aware of the existence of the other 2 GB of the memory on the platform?
2- I prefer that each guest OS manage directly its memory without the intervention of the host hypervisor (in other words the guest physical address reflect the actual hypervisor physical address), in such scenario can I resort to a XenARM-like hypervisor and just disable the second stage translation in the Xen hypervisor code? Would that work or is there actually a better way to do it? Please share your experience
Best wishes.
Thanks daith and Martin,
@daith: yes I agree that the overhead of second stage translation translation is very small and that's why hardware second stage page-table walk were made (let's forget about how much very small ). Further, you mentioned that my goal is very difficult thing to do; why is that in your opinion? what are the challenges that I will be facing?
Please let me state briefly that my goal is to host two OSes with pseudo-complete disengaging of the hypervisor. The scheduled OS is itself responsible for its own memory mgmt, interrupt handling and all other privileged operations. My bare-metal hypervisor does nothing by periodically schedule one of the two OSes based on a timer interrupt. Any kernel access to this timer is trapped to the hyp etc..
Martin idea on having flat having flat mapped addresses (i.e. IPA==PA) together with hyp translation is very interesting, could you please elaborate more on how to integrate it in my design to achieve my upper-mentioned design goal.
Thank you so much.
The hypervisor would have to inspect and monitor all accesses to the page tables of the guest OS if it did not provide a second level of translation. Otherwise the guest OS can just stick in the physical address of an area it should not access or try accessing some I/O device it should not access. This would probably mean checking the page tables when the guest OS loads a translation table base and protecting it from reads and writes. It would then need to catch the interrupt when any instruction accessed a table and emulate the instruction after checking that it was admissible - i.e. that it only allowed access to area the guest OS was supposed to be able to access, or for a read that it got back what it expected rather than detecting any changes by the hypervisor to disable access.
The second level of translation is invisible to the guest OS. It provides a virtual environment for the OS so even though it can set up and change page tables what it thinks of as a physical adress is in fact checked and translated by the second level set up by the hypervisor.
By the way here's some figures on overheads
Xen on ARM - How fast is it really?
As you can see the double translation isn't a problem, the overheads are in problems virtualizing interrupts and I/O.