shithub: vmxsmp

Clone

Last commit

runvm change

About

** INSTALL ** 

-> cp devvmx.c /sys/src/9/pc/devvmx.c
-> Recompile the kernel and reboot:

cd /sys/src/9/pc64
mk clean
mk 
mk install
bind -a '#S' /dev
9fs 9fat
cp /n/9fat/9pc64 /n/9fat/oldpc64 # backup 
cp /amd64/9pc64 /n/9fat/9pc64
fshalt -r

-> Build vmx:

mk
mk install

-> Install alpine linux, 

./runvm alpineinstall

You should see 4 cores in /proc/cpuinfo

-> Use alpine linux, 

./runvm alpinerun

-> These scripts assume the existence of /net/ether0

** NEW FEATURES **

-> SMP, to specify number cores use -x option in vmx, by default 4 cores.

-> Faster vioblk, on my laptop I can get up to 240Mb/s vs the 
previous 180Mb/s . Presumably vionet is also faster. 

** BUGS **

-> OpenBSD is slow
-> 9front is slow when two disks are attached
-> Mouse is slow
-> Cannot boot with more than 4G (trivial to fix though)

** (PREVIOUS) NOTES **

-> In devvmx.c we add two features, setting the tsc offset and VMX PREEMPT. Therefore,

**Running this requires recompiling the kernel with the provided devvmx.c file**

-> Proper cleanup is not implemented. Run killvmx.rc script after you are done. Running two vmx instances at once will most definitly result in corrupted state in both since we use the same shared segment names for shared memory right now. 

-> Before entering the loop we record the timer that is the first to expire and use VMX PREEMPT to trigger a VM exit after that time. 

-> All interrupts are treated as IPIs

-> OpenBSD is very slow with SMP, faster with nvcpu = 1. I do not understand why. 

-> Plan9 is slow if you don't add -n /net/ether0. I understand why but can't be bothered to fix it right now. 

-> Linux seems to run just fine. 

-> The architecture is a major overhaul from the previous vmx which relied on entering i8042 legacy mode. In our case we have to deal with several timers. Using VMX PREEMPT appeared to be the simplest way to manage all this complexity. 

-> Code is very messy right now. AI was used to generate the very boring boilerplate e.g. APIC and MP tables, and IO port handling. Those parts can be probably dramatically simplified. 

-> Right now it will crash if you want to use more than e.g. 2G of RAM, this is trivial to fix but it is not a priority at this stage.