Tim Roscoe gave an interesting Keynote at OSDI '21 titled "It's Time for Operating Systems to Rediscover Hardware" - https://www.youtube.com/watch?v=36myc8wQhLo. He was involved with the Barrelfish project.
IIRC, colinux is similar to user mode Linux, which boots a kernel in userland. That is, the kernel runs under windows as an application rather than alongside it.
Reminds me of OpenVMS Galaxy on DEC Alpha systems, which allowed multiple instances of the OS to run side by side on the same hardware without virtualization.
"while sharing the underlying hardware resources"? At the risk of sounding too positive, my guess is that hell will freeze over before that will work reliably. Alternating access between the running kernels is probably the "easy" part (DMA and command queues solve a lot of this for free), but I'm thinking more of all the hardware that relies on state-keeping and serialization in the driver. There's no way that e.g. the average usb or bluetooth vendor has "multiple interleaved command sequences" in their test setup.
I think Linux will have to move to a microkernel architecture before this can work. Once you have separate "processes" for hardware drivers, running two userlands side-by-side should be a piece of cookie (at least compared to the earlier task of converting the rest of the kernel).
Will be interesting to see where this goes. I like the idea, but if I were to go in that direction, I would choose something like a Genode kernel to supervise multiple Linux kernels.
This is something that was actually implemented and used on multiple platforms, and generally requires careful development of all interacting OSes. Some resources that have to be multiplexed are handled through IPC between running kernels, otherwise resources were set to be exclusively owned.
This allowed cheap "logical partitioning" of machines without actually using a hypervisor or special hardware support.
Today, you can grab a physical NIC and create some number of virtual NICs. Same for GPUs.
I guess the idea is that you have some hardware, and each kernel (read "virtual machine") will get:
- some dedicated CPU
- some physical memory
- some virtual NICs
- some storage, maybe (if dedicated; if through network, then nothing to do here)
- maybe a virtual GPU for the AI hype train
Every kernel will mostly think it owns real hardware, while in fact it only deals with part of it (all of this due to virtualized hardware support that can be found in many places)
This feature does not seem like a general-usage feature, which can be used in our laptop
It’s not clear to me but do these kernels run directly on the hardware? If so how are they able to talk to each other, DMA? That could open up some security flaws, hopefully they thought through that
That's cool! Similar is the idea of running a single large VM across multiple hosts. There have been several iterations of that idea, the latest being a presentation at this year's KVM Forum: GiantVM: A Many-to-one Virtualization System Built Atop the QEMU/KVM Hypervisor - Songtao Xue, Xiong Tianlei, Muliang Shouhttps://kvm-forum.qemu.org/2025/
There are various hardware singletons that need to be managed for this to work properly. This raises many questions.
Which of the kernel does the PCI enumeration, for instance, and how it is determined which kernel gets ownership over a PCI device? How about ACPI? Serial ports?
How does this architecture transfers ownership over RAM between each kernel, or is it a fixed configuration? How about NUMA-awareness? (Likely you would want to partition systems so that RAM is along with the CPUs of the same NUMA node).
Looks to me that one kernel would need to be have 'hypervisor'-like behavior in order to divvy up resources to other kernels. I think PVM (https://lwn.net/Articles/963718/) would be a preferred solution in this case, because the software stack of managing hypervisor resources can already be reused with it.
27 comments
[ 5.1 ms ] story [ 29.2 ms ] threadIf you need more security/isolation, go to a VM or bare metal.
[0.5]: https://en.wikipedia.org/wiki/Exokernel
[1.5]: https://wiki.osdev.org/Exokernel
[2.5]: "Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration." — Stan Kelly-Bootle
https://barrelfish.org/
https://nrkernel.systems/
https://www.digiater.nl/openvms/doc/alpha-v8.3/83final/aa_re...
I think Linux will have to move to a microkernel architecture before this can work. Once you have separate "processes" for hardware drivers, running two userlands side-by-side should be a piece of cookie (at least compared to the earlier task of converting the rest of the kernel).
Will be interesting to see where this goes. I like the idea, but if I were to go in that direction, I would choose something like a Genode kernel to supervise multiple Linux kernels.
This allowed cheap "logical partitioning" of machines without actually using a hypervisor or special hardware support.
Today, you can grab a physical NIC and create some number of virtual NICs. Same for GPUs.
I guess the idea is that you have some hardware, and each kernel (read "virtual machine") will get:
Every kernel will mostly think it owns real hardware, while in fact it only deals with part of it (all of this due to virtualized hardware support that can be found in many places)This feature does not seem like a general-usage feature, which can be used in our laptop
https://sourceforge.net/projects/kerrighed/
Which of the kernel does the PCI enumeration, for instance, and how it is determined which kernel gets ownership over a PCI device? How about ACPI? Serial ports?
How does this architecture transfers ownership over RAM between each kernel, or is it a fixed configuration? How about NUMA-awareness? (Likely you would want to partition systems so that RAM is along with the CPUs of the same NUMA node).
Looks to me that one kernel would need to be have 'hypervisor'-like behavior in order to divvy up resources to other kernels. I think PVM (https://lwn.net/Articles/963718/) would be a preferred solution in this case, because the software stack of managing hypervisor resources can already be reused with it.
Could the new kernel be genetically scored for effectiveness (security, performance, etc), and iterated upon automatically, by e.g. an AI?