To be fair, Zurich does have mountain view too.

The bug is that bit 0 of `mepc` is hardwired to 0, so when temporarily storing x5 in `mepc` we lose that bit.
Because of that I don't think it is possible to increment `mepc` without modifying the other registers in only 3 instructions on RISC-V, is it?

Another way to think about the VMware hypervisor is that it works around the non-virtualizability of x86_32 by re-writing the problematic instructions on the fly, so we could also say that VMware is an hypervisor for a subset of x86_32 which patches all programs using forbidden instructions.

The problem is that running the kernel in an emulator is too slow. The way VMware fixed the problem is by running the kernel in a fast emulator, using dynamic binary translation, the same idea behind the QEMU emulator.
They achieved almost native performance on kernel code.

As noted in the virtualization requirements paper, very few architectures were virtualizable at the time, but the paper (from the 70s) also predicts the solution: "hybrid virtual machines".
The idea is simple, virtualize only the user space programs, and run the kernel in an emulator.

The history of virtualization is fascinating, a few more foundational papers for the curious:

- The design of the original VMware hypervisor: infoscience.epfl.ch/server/api/c...
- The virtualization requirements: dl.acm.org/doi/pdf/10.1...

Super cool work!

I started looking into information flow control for agents recently, and I was thinking about your work on static analysis of shell scripts. Would be interested to chat if you're thinking about going deeper in that direction.

The next step is to add support for virtual memory, but that requires a bit more work as I need to add support for monomorphization to the compiler to work around some const generic expr limitations.

To me, this is super cool because now we can query the hardware from a Rust unit test running on the host! That will make it trivial to test basic operations such as TLB flush, memory protection, trap vector configuration, and so on, all directly from unit tests.

Of course, the same technique can be applied to other (non-Rust) hypervisors. The details and theory behind are in the paper: charlycst.github.io/papers/light...

See you in Banff!

We will try to run Miralis on it, which is an M-mode software-based hypervisor. The H extension adds hardware support for S-mode virtualization. In theory both are orthogonal, which means that we should be able to run an H-mode hypervisor on top of a virtual M-mode.

Ho cool! I plan to make the website repo public after some cleanup and writing some doc, but I can add you if you want to take a look at the code for plotting.

OSFC has been a great experience, lot and friendly people and very interesting talks and discussions.