Will the Pyra support KVM from the start ?


I don't think many people like Android per se, they just like the huge number of apps available for it.
 
I do like Android for the purpose it serves, as a phone OS. I could like a full featured Linux install as a phone OS, but it would need a lot of tweaks that have already been done to Android.

This is distinct from what I'd like to use the Pyra for, which is portable gaming/computing with phone features, and for that I'd need a full featured Linux and additional tweaks would not really be necessary.

Different use cases require different solutions, and Android fits its use case very well.
 
This would be my ideal way for how to run the pyra in my opinion. KVM hypervisor with guests (debian/android/ubuntu etc) images all virtualized. You could jump between them on the fly and have them run in parallel if needed. Suspend the unused OS while not in use, you could even get creative with RDP sessions and run apps on one from the other. I haven't seen anyone really jump into the A-15's virtualization features yet in a practical released product, would be really sweet if the pyra had the first usable solution in a consumer product.
 
Last edited by a moderator:
SNESFAN said:
This would be my ideal way for how to run the pyra in my opinion. KVM hypervisor with guests (debian/android/ubuntu etc) images all virtualized. You could jump between them on the fly and have them run in parallel if needed. Suspend the unused OS while not in use, you could even get creative with RDP sessions and run apps on one from the other. I haven't seen anyone really jump into the A-15's virtualization features yet in a practical released product, would be really sweet if the pyra had the first usable solution in a consumer product.
Click to expand...
That... is a great idea.  *crosses fingers in hope*

-Glyph Reader
 
SNESFAN said:
This would be my ideal way for how to run the pyra in my opinion. KVM hypervisor with guests (debian/android/ubuntu etc) images all virtualized. You could jump between them on the fly and have them run in parallel if needed. Suspend the unused OS while not in use, you could even get creative with RDP sessions and run apps on one from the other. I haven't seen anyone really jump into the A-15's virtualization features yet in a practical released product, would be really sweet if the pyra had the first usable solution in a consumer product.
Click to expand...
If you won't loose too much power if everything is virtualized.
 
I think you would loose more power to the parallel processes using CPU time than what you would lose just having the machine virtualized. My understanding is hardware level virtualization is done through enhanced IO schedulers, memory is segmented out dynamically etc. I'm not sure if there is a significant amount of cycles spent running through a virtual machine with hardware virtualization vs natively on bare metal. That might be more of a exophase question. From my friend that specializes in vm's he says its not much different than sandboxing a program, and the only additional resources when the other guests are either suspended or off are the added memory allocation for the other guests. Where the parallel processes are just sharing their time with active hardware use. (CPU/GPU/network/input) I'd be curious to find out how many cycles it takes for a thread of one OS to be switched for the next, and single core flipping vs dedicating a core to each.
 
There is some virtualization overhead and it's reported to be similar on ARM to what it is on x86, something like 0-20% penalty depending on task. The penalty comes from having to emulate virtual hardware, like disk IO where it has to constantly switch worlds from virtualized to host to handle the requests, and that switching is not cheap.

Another problem I see is that you're going to run out of RAM pretty quickly, especially with Android which eats insane amounts of RAM for nothing.

Passing though OpenGLES for Android is going to be big challenge too (especially if you want to do it efficiently), Android is pretty much useless without GL.
 
Passing though OpenGLES for Android is going to be big challenge too (especially if you want to do it efficiently), Android is pretty much useless without GL.
Click to expand...
Apps like Whatsapp and Skype (text messages) could still be usefull even if the system is slow.
 
notaz said:
There is some virtualization overhead and it's reported to be similar on ARM to what it is on x86, something like 0-20% penalty depending on task. The penalty comes from having to emulate virtual hardware, like disk IO where it has to constantly switch worlds from virtualized to host to handle the requests, and that switching is not cheap.
Click to expand...
I'm trying to find data to support this, but I have seen claims ranging everything from "minimal overhead" to calculated benchmark numbers of 30-80% which seems rather high and not even close to what I experience on a desktop with a full blown OS as the host. They were comparing things from KVM to VMware, Xen, virtualbox etc etc. But no trending data that would lead to a definitive answer.

I've always saw embedded virtualization as the future, and have been really trying to get my feet wet in the subject, but if the overhead is that bad I might not bother. Kind of supports the fact that no solution currently exists in a product yet, if the performance hit is that significant on a system where every clock cycle matters.

Do you have any further reading on this that you would suggest?
 
This is an interesting article, although most of it is rather technical, the final parts are not:

https://lwn.net/Articles/557132/

But in general it should be interesting, it's certainly worth it to get it working on default OS, even if it can't run Android at first. Don't know about day 1 though.
 
that was exactly what I was looking for thanks notaz. Some thick reading for sure, but extremely valuable and bookmark worthy. This definitely looks more solid than the generalized claims and possibly even marketing ones from ARM and what I was hoping to find. Really interesting bits about the use of qemu in conjunction with KVM which I was not aware of.

but more to the point, the part I was looking for specifically

Our measurements using both micro and macro benchmarks show that the overhead of KVM/ARM is within 10% of native performance on multicore platforms for balanced workloads. Purely CPU-bound workloads perform almost at native speed. The relative overhead of KVM/ARM is comparable to KVM on x86. For some macro workloads, like Apache and MySQL, KVM/ARM even has less overhead than on x86 using the same configuration. A significant source of this improved performance can be attributed to the optimized path for IPIs and thereby process rescheduling caused by the VGIC and generic timers hardware support.
Click to expand...
So yea, definitely going to look into this some more, looks promising for sure.
 
Last edited by a moderator:
Whatsapp - Look at Yapari for N900. Maybe this can be ported easily enough.
 
Or Mitakuuluu for Jolla (github). It's Qt5 based and quite nice :)

EDIT: Mitakuuluu seems to actually be a descendant of Yappari.
 
Last edited by a moderator:
You must log in or register to reply here.

Similar threads

Grench
Virtual Machines on a Pyra?
Replies
15
Views
6K
TrashyMG
TrashyMG
slaanesh
Psp Kvm For Gp2x?
Replies
3
Views
2K
woogal
W
T
Sun's Kilobyte Java Virtual Machine
Replies
1
Views
2K
ravuya
R
Djoga'Ro
Has someone detailed intel on DDM in context of KM/KVM switches laying around to throw at me?
Replies
0
Views
3K
Djoga'Ro
Djoga'Ro
Blue Shadow
Release Barrier
Replies
5
Views
3K
RDF300
RDF300
Back
Top