Closed lonnietc closed 2 years ago
Hi,
from its design perspective, L4Re is a microkernel system, means it runs, potentially many, isolated services that can be used by programs and other services. Running a VMM is basically "just" a program on the system, it's not special in any regard. However, that is what makes the system a "hypervisor" in the sense it runs virtual machines. Having said this, regarding drivers, it's a microkernel system in which drivers can be placed and run in dedicated microkernel programs. But implementing drivers is typically cumbersome work. Another option is to use existing software/drivers and run them on the system. On way (but not the only one) is running this existing software in a VM. Of course, there can be the only one VM having all the drivers of the platform which would then be like a Dom0. There could be multiple VMs providing access to different devices. There can be a mix with microkernel programs, depending on use-cases, resources, etc.
I'm sure uvmm could also run Windows, however I'm not aware of any investigations in running Windows on uvmm. I you have any, please let us know :)
@alacko Thanks for your response on this and I am getting a better understanding of the L4Re design.
Right now, I am working on x86_64 based systems for development and testing:
I have been able to compile up L4Re with uvmm following the direction in the Repo but still would like to:
A.) Find the L4Re GUI libraries and compile up some graphical examples like: https://l4re.org/screens.html
B.) find some pre-built ISO images that would simply boot up just to test on my platforms like I did in the past with NOVA booting their old, but impressive Demo 0.3 (http://os.inf.tu-dresden.de/nul/NOVA-0.3.iso.bz2) for their old site: http://os.inf.tu-dresden.de/nul/
I actually would like to see if I could either find, or build, a type of replica of that NOVA-0.3 demo but based upon L4Re instead since I really like what I see in this work.
While, I truly thought that NOVA was impressive and was even able to build up everything from the sources including building the ISO's of the demos as well as utilize the NRE framework, it is really old, not supported, and would require substantial work to add in support libraries to make it useful from what I see. The only ones to have done something seem to be Bedrock systems, and Cyberus Technology but those are closed source (mostly) commercial companies.
I think that L4Re may be the best way to go for what I have in mind. Thanks
Hi, I do not see an issue with the systems. The screenshots are relatively old and I'm afraid most of them are not available for rebuilding because they have not been preserved or are just showing a WiP status. http://l4re.org/download/snapshots/pre-built-images/ has images, however, not ISOs, just the images that can be booted with GRUB (or u-boot, or...). Enabling the virtualization demo for x86 is on the top of list. Most of the things are there, just minor things remaining to enable it. Switching between VMs would be working via Ctrl-E 1, 2, etc...
@alacko Thanks for the post on this and I tried the Pre-Built images. I could run a simple x86 demo but it was text-based and ran through your script. I would be interested in seeing how to build up a simple ISO with a graphical interface or VM app running so that I can boot on real hardware (x86_64 to see it in action beyond running from a script on my Ubuntu 20.04 system.
Hello,
While I am still looking at possibly using L4Re, it also seems like a challenging road to get things to work on the x86_64 platform and most of the L4Re/Fiasco efforts are mainly for ARM which is their automotive niche and understandable.
Some demos that Adam Lackorzynski put out had problems with the framebuffer on the bare metal hardware of mine and will take some investigation to see about getting things to work as well as I was not able to convert and run any type of MultipleVM (from the L4Re ARM example) on my x86_64 hardware.
If I were to go back to the NOVA/NRE (Nils Asmussen) then I would still be faced with the challenge that I need a LibC for that combination but that it actually boots well on the x86_64 in the basic dated demos that that they have previously setup.
I am now wondering if it might be a good idea to try and use the "uvmm" as the VMM on the NOVA platform instead of the current Seoul VMM which needs a lot of work.
Alternatively, I could possibly investigate going back to:
NOVA Microhypervisor --- https://hypervisor.org/ --- Love the design and simplicity but it is old and has no support or useful VMM capabilities beyond Seoul (Alpha). With spinoffs of Cyberus Technology (https://blog.cyberus-technology.de/) and BedRock Systems (https://bedrocksystems.com/use-cases/)
ACRN Hypervisor --- https://projectacrn.org/ --- Xen Dom0 type design that I do not really like and no dynamic allocation capabilities.
XVisor --- http://xhypervisor.org/ --- Interesting monolithc design approach for everything.
Genode --- https://genode.org/ --- Too hard to work with and the licensing is not viable for my needs.
Ultimately it all comes down to funding and what it will cost to build up a simple PoC and as I am doing this project all on my own at this initial stage, then I will just have to figure out things on my own.
Anyway, Thanks again and I will do a Pros/Cons evaluation on everything to see what the best options are at this stage.
Best Regard
Hi, just a comment on the framebuffer problems of yours. Most likely the reason that it doesn't work on your hardware, is that the BIOS no longer supports CSM and thus doesn't have a VESA framebuffer. You would need to implement support for EFI GOP or implement support for the framebuffer of the graphics card in your system.
@icedieler Hello.
I will dig more into the code on this.
Can you please tell me if the "uvmm" will run x86_64 bit based OS's or is it limited to x86_32 based OS? Thanks
Hi @lonnietc, the uvmm can only run x86_64 guests. The development happens on desktop/mobile CPUs, thus I cannot tell in how the uvmm runs on a XEON server CPU. SandyBridge generations might have other issues. IIRC we had issues with Nehalem generation mobile CPUs, but I don't know the details from the top of my head, thus I can't tell if sandy bridge has all the CPU features we expect. We try to get uvmm running on CPUs starting at the Haswell generation. On the up side, uvmm should run fine on the NUC's Kaby Lake generation CPU.
On the question of uvmm on NOVA: Never tried it, but I doubt it will run.
Hello,
Hope that your are doing well and also hope that this is the right place to discuss this.
I have been working towards a small-footprint RAM-based Type-1 hypervisor and have explored numerous possibilities in the past ranging from the XCP-ng, Genode, Sculpt, ACRN, and NOVA MicroHypervisor to name a few.
After a lot of research, I settled down on NOVA since I liked it a lot, but the problem is that is is a bit dated and hard to get going with on the development since it needs a complete VMM before if could be used as a viable hypervisor.
Recently, I came across L4Re and it seems like it could be a possible, and more advanced solution to use as a base along with the uVMM project but I am just not clear on some of its capabilities.
In my reading here, it also seems that things are laid out in a type of Xen topology in that the system drivers all run in a type of Dom0 VM and it would be my interest to partition them off into their own isolated driver VM's to get away from the the whole Dom0 idea. Of course this also presents its own set of challenges, but is something that I think if probably achievable with a bit of work.
The other thing that I would be interested in learning about is if the uVMM could also run scaled down Windows guests even in a headless way or with a virtual console that can be paged.
Any thoughts would be greatly appreciated.