Virtual Machines on a Pyra?

[Grench]

So, I started looking into the state of ARM virtualization. Just search and reading.

This is interesting - looking at using KVM to install an ARM Ubuntu Linux guest OS on an ARM Ubuntu Linux host using a Cortex A-15:
https://systems.cs.columbia.edu/arc...d-implementation-of-the-linux-arm-hypervisor/

This is the other half - looking at using KVM to install an ARM Android Jellybean guest OS on an ARM Android Jellybean host using a Cortex A-15:
http://www.virtualopensystems.com/en/solutions/guides/kvm-android-on-fastmodels/

So - the question is - does the combination of these two exercises put us closer to having an Android Jellybean guest OS on an ARM Debian Linux host using a Cortex A-15? I.e. Android VM on Pyra?

 

[FBnil]

Nice links @Grench!

I did some reading about running Android inside Linux shashlik (which has a Qemu fork) and ARChon
note that I did not find references to ARM, just x86. However... we seem to have some Qemu guru's on the forum...

 

[sebt3]

why virtualize when you can just "contain"
Anyway, any solution to have both OS at the same time will need lot's of works, why choosing the solution with a performance penalty ?

 

[Grench]

why virtualize when you can just "contain"
Anyway, any solution to have both OS at the same time will need lot's of works, why choosing the solution with a performance penalty ?

Why? In order to have contained sand boxes for the guest OS. I.e. have a Pyra running Debian with an Android VM for work and an Android VM for play/games. A person could even have a 3rd Android VM that they can safely side-load 'whatever' onto it.

Instead of development work on an application to application basis, this would theoretically be a single-development to enable an entire array of applications. More equivalent to a system emulator than a single game port. From the above examples, it appears that much of the, "lot's of works," has already been done. Yes, there would be more to do - BUT - there is already the above proofs of concepts done directly on A-15 cores.

Examine the results in the links. The performance penalty is minor.

 

[sebt3]

you got me wrong... I was suggesting solution like anbox. Android nowadays run pretty standard linux kernel. So an android container (think docker) is clearly doable.
Running android on bare metal will always be faster than in qemu, no matter how low the performance cost are advertised to be.

 

[Grench]

you got me wrong... I was suggesting solution like anbox. Android nowadays run pretty standard linux kernel. So an android container (think docker) is clearly doable.
Running android on bare metal will always be faster than in qemu, no matter how low the performance cost are advertised to be.

I don't really want Android to be running on the bare metal. I would much prefer for Android to not have direct access to the hardware or storage. I.e. keep it contained so it can only blow up or make insecure it's own instance.

 

[JonnyH]

I don't really want Android to be running on the bare metal. I would much prefer for Android to not have direct access to the hardware or storage. I.e. keep it contained so it can only blow up or make insecure it's own instance.

Android has a hard requirement of GLES2 support nowerdays, and the sgx doesn't support any virtualisation extensions and the driver will not support any 'pass through' modes without large amounts of work. I am unsure about the functioning/performance of OpenGL-level virtual machine passthrough.

You can use linux containers to restrict access to specific devices or storage locations quite easily without a VM, though you still have to trust any exposed devices within that container (which would include the gpu driver for one, though this *is* open source and it's MMU interactions can be verified, it still runs a closed firmware and verifying all the code paths in the 'open source 'kernel driver would be a massive pain if that's required for trust).

 

[Klumpen]

Anything new about Alien Dalvik?
https://pyra-handheld.com/boards/threads/running-android-apps-in-pyra-os.73573/

 

[Askarus]

Anything new about Alien Dalvik?
https://pyra-handheld.com/boards/threads/running-android-apps-in-pyra-os.73573/

Isn't Anbox the better solution now?

 

[Grench]

Isn't Anbox the better solution now?

Anbox is still very Alpha. That said, it holds good promise for this type of application.

It would be interesting to see someone try it on a dev board. @TrashyMG, if you have the time and inclination, can you give it a whirl?

 

[PCXT]

About VMs, I have different question related to performance: I know that QEMU can emulate x86 architecture. But how efficiently? How fast PC can be emulated on ARM processor in Pyra? Like 286/16? Or rather 386/40? I'm thinking about old DOS games here and not only DOS games as there is a bunch of old DOS software which can operate even today and has no open-source or lightweight replacements.

 

[TrashyMG]

About VMs, I have different question related to performance: I know that QEMU can emulate x86 architecture. But how efficiently? How fast PC can be emulated on ARM processor in Pyra? Like 286/16? Or rather 386/40? I'm thinking about old DOS games here and not only DOS games as there is a bunch of old DOS software which can operate even today and has no open-source or lightweight replacements.

QEMU is pretty poor. Exagear Desktop a commercial solution does it considerable faster. As for Dos, DOSBOX works wonders on the OMAP5.

Some things I've done on the OMAP5 devboard a long time ago, Some of these would be better if 3D acceleration was working:

*Diablo 2 - We have a native port, but this is through Exagear Desktop + WINE:
*Unreal Tournament, Software Rendering using Exagear Desktop and the x86 Linux version of UT
*fairly poor performance, just kind of shows where the lines are.

 

[Grench]

Some of these would be better if 3D acceleration was working:

Has anyone seen any (recent) updates on efforts toward getting the 3D driver working?

 

[TrashyMG]

Has anyone seen any (recent) updates on efforts toward getting the 3D driver working?

Well it does work at least it did on the Jessie install, just currently there is an issue running it at the same time as the screen rotation. I haven't played with it with Exagear Desktop yet.

 

[Grench]

Well it does work at least it did on the Jessie install, just currently there is an issue running it at the same time as the screen rotation. I haven't played with it with Exagear Desktop yet.

So turn your monitor connected to the dev board 90* to landscape and get to playing?

 

[TrashyMG]

So turn your monitor connected to the dev board 90* to landscape and get to playing?

Yeah currently the OS default is set to 90° , but I have set the boot arguments to set it to 0° or regular landscape mode. However It's still running the same rotation method that is preventing the SGX driver from being enabled... I'll need to re-remember how I disabled this. I'm also not sure the SGX kernel drivers are compiled on the latest test kernel I'm on. I do have my old Jessie install on another SD card, but that has been feeling a bit too old.