We have moved to a new Sailfish OS Forum. Please start new discussions there.

Breaking free of kernel version requirements due to binary blobs from Qualcomm/Broadcom et. al.

asked 2016-06-08 01:21:32 +0300

00prometheus gravatar image

updated 2016-11-02 02:14:40 +0300

As I understand it, one of the problems preventing kernel upgrades is that there are binary blobs for the hardware layer that restrict what kernel versions to run. I have an idea for a way around that limitation:

Build a stripped down kernel that follows the binary blob restrictions, then use that as a hypervisor for another kernel that actually runs the real OS. So Sailfish OS will run in a virtual machine using its own unrestricted kernel, under a hypervisor that runs the binary blobs with all its restrictions.

Edit: The core issue regarding this scheme is performance impact. This is hard to predict, modern virtualization can have almost no performance impact; it depends heavily on what hardware support for virtualization one can expect now and in the future (virtualization support in ARM has improved dramatically the last few generations). We might also be helped by the fact that only a single specific OS will ever run in the VM, so both guest OS and the Hypervisor may be specialized for each other.

Edit2: A possible alternative is to turn it around. Make the hypervisor the main OS, and make sure it performs HW pass-through to the guest. Then put the binary blobs in the guest, along with a minimal blob-compatible kernel and let the guest serve the blob-liberated hypervisor.

edit retag flag offensive close delete



even I use virtualization daily at work, I prefer that my phone OS to be as close to metal as possible.

tvicol ( 2016-06-08 10:12:58 +0300 )edit

Virtualization is an admin-word for I don't care how dangerous and slow it is.

hoschi ( 2016-06-08 12:08:12 +0300 )edit

Interesting idea. If the hypervisor doesn't eat too much resources and the kernel and hardware allow hardware assisted virtualization then it could be worth giving it a shot, but as far as I know, ARM processors do not support virtualization at hardware level.

shfit ( 2016-06-08 13:02:07 +0300 )edit

@00prometheus I just do not see the point of a kernel upgrade. It does not stand in any balance with the amount of work/complexity/system-slowdown you'll introduce!

lpr ( 2016-06-08 14:12:58 +0300 )edit

@00prometheuswrong, it is easy to predict a huge performance impact on jolla1! With no ram left (guest kernel + hypervisor + host-kernel + aliendalvik... and you even haven't started one single app), lost of a lot GPU power, even if you get hw acceleration working (arm has no features to virtualize hw gpu as intel gen7.5+ has), lost of ability to play h.264 encoded videos (no hardware codec in guest mode...)... no way! Let's hope for kernel 3.4.112 being implemented as an update soon.

lpr ( 2016-06-08 17:04:32 +0300 )edit

3 Answers

Sort by » oldest newest most voted

answered 2016-06-08 10:15:41 +0300

updated 2016-06-08 10:22:34 +0300

I don't think that's a good idea; just imagine the performance loss on already not-that-fast phones.
Running Android apps would be a lot slower than it already is and the battery would run out a lot faster.
I'm pretty sure there are more disadvantages than advantages with this idea. It would also take a lot of non-trivial knowledge and manpower to make it work.

edit flag offensive delete publish link more


Running under hypervisor is not that much of a performance issue really.

As for usability of Android or Native apps, I don't believe there would be any noticeable performance degradation.

juiceme ( 2016-06-08 11:30:12 +0300 )edit

there is such a thing like virtualization extensions in ARMV7-A in principle but there is most likely no way that this SoC implements it. @juiceme you will notice that you cannot even watch a video (in browser or somewhere else) if you have no access to qualcomm hardware codec in your guest, despite the loss of main memory that will slow down everything a lot...

lpr ( 2016-06-08 13:42:46 +0300 )edit

Thanks for the clearup, @lpr.

Have you made some experiments with virtualization on armv7, or do you extrapolate that from experience on some other HW?

juiceme ( 2016-06-08 13:52:47 +0300 )edit

ARM describes the field of interest of these extensions (Cloud, robustness req. implementations, storage). In one sentence: large amount of main memory or very reduced but very robust application... The thing with hardware codec is not impossible to do but there isn't even vaapi/vdpau etc. in x86 guests, and the amount of RAM you need for guest kernel you could simply subtract from available RAM...

lpr ( 2016-06-08 14:04:28 +0300 )edit

answered 2016-06-08 21:48:01 +0300

ced117 gravatar image

Just tell Qualcomm, Broadcom and all the others to provide us the source code of these binary blobs.

We could all help each other to solve bugs and similar things.

edit flag offensive delete publish link more


Sure, I would rather have that too, but we have wanted that for decades! What do we do until it happens?

00prometheus ( 2016-06-09 16:08:53 +0300 )edit

Well, learning how these blobs works to do open source drivers will take too much time... sadly.

Virtualization is maybe some "temporary" idea but no the best, as @jollailija said.

Aside of that..., i know, i'm repeating myself but, we clearly need the source code.

If only Jolla had access to it...

ced117 ( 2016-06-09 20:25:23 +0300 )edit

answered 2016-06-10 00:04:33 +0300

tortoisedoc gravatar image

I do not see a point in this; the limitation is not only the version nr of the kernel; but also features which are not available on older kernel releases (and on which your hypervisor would rely on). Zero real gain there. Only virtual. Meh.

edit flag offensive delete publish link more


A guest kernel can certainly have access to features that are not present in the hypervisor kernel. That is how you can run a Linux guest under a Windows hypervisor, for example. It's really the main point of virtualization...

00prometheus ( 2016-11-02 02:01:08 +0300 )edit

Yea, that called software emulation. But it does not change the fact that the guest kernel will be run by the host one. Plus, emulation is slow on high-end servers, not to speak on a (probably crappy hw-wise) SFOS one.

tortoisedoc ( 2016-11-02 06:53:03 +0300 )edit

No, software emulation is completely different. Emulators are programs that act the way some hardware does; for example performing the operations of a certain CPU, so that programs compiled for that CPU can be run in a different CPU. Virtualization is very different, you don't emulate any hardware at all, you only run an OS as an application under another OS. When virtualization was new (about a decade ago), there were significant performance hits, but with modern virtualization those problems are solved. Modern servers almost always run virtualized because it is actually faster than running unvirtualized (mainly because of parallelizing and better time-sharing of hardware).

00prometheus ( 2016-11-03 03:14:41 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2016-06-08 01:21:32 +0300

Seen: 1,293 times

Last updated: Nov 02 '16