We don't think it is needed. Currently, the only thing which is stopping it from running on bare-metal no hypervisor are some drivers for virtual devices (eg. virtio net driver).

Challenge is, ofc, supporting wide range of hardware options, but we don't intend to. We plan to support only modern x86_64 CPUs (arm is on the roadmap) and a select few NICs.

Current implementation is written to be hosted on public cloud, so we implement what is needed for that, but in the future we intend to allow self hosted version, but only on selected server hardware.

Now, if we have "big" server with like 256 cpus, etc. we can still split it many smaller "vms". Since the only code that runs with Hardware Manager is code we write, we can just add config options which pin execution to resources, eg. ram, we can just allow it to use from 4gb-8gb phys addr. Shared hardware like NIC is a bit trickier, but we do have some tricks up our sleeve which allow sharing.

We are actively working on it (also writing a paper). Performace gains like this aren’t unexpected for systems like this see: https://www.cs.cit.tum.de/fileadmin/w00cfj/dis/papers/cumulu...

That type of tech + redis being quite bad implementation allows those gains (up to 2000%, we even have commands showing ~2200%, mostly lists since they have very cache unfriendly implementation)

Hi, we fixed the main link now (hopefully it works now, thanks for pointing it out).

This is just initial version of the website, we are working on a new one.

Glad you find it interesting :)

If you have some questions feel free to ask.

Yes, since we never run untrusted code, there is no reason to use more complex mechanism. Memory is 1-1 mapped with physical ram. This also allows us to control cache even better (side note, we use huge 1gb pages for memory mapping, to ease pressure on TLB/MMU).