Not a lot of meat on this, but it looks nice from glancing at all the bits. I would recommend that you read the CPUID bits from the real CPU and copy most of them over so that the kernel can enable features like SSE4.x, AVX/AVX2 and various others. Use KVM_GET_SUPPORTED_CPUID and then KVM_SET_CPUID2.
I would also set the CPU name to KVMKVMKVM and enable a few of the paravirtual devices like KVMCLOCK.
Once I read an LWN article about KVM [1] and it introduced a tool called kvmtool [2] and a tiny test program illustrating how to use the KVM API. However the sample program was too simple and the latest kvmtool seemed too complex for my taste.
Wiser seems simple enough (5 small enough .c files). If it is capable to boot Linux, it can be a great learning material. Great job!
Why do you call it a hypervisor when it's more like a VMM?
Even the name "VMM" is a quirk of KVM; before KVM, "virtual machine monitor" was another name for a hypervisor: that is, the thing that ran on the bare hardware and provided the virtual hardware interface to the VM. KVM has fairly unique architecture, where a VM is basically a process.
I'm willing to tolerate that "drift" of meaning, because we need a word for the piece of software which converts a process into a VM, and "VMM" is a good fit. But I'd have to really object to the idea of calling such a piece of software a "hypervisor".
If your plan is to make wiser into an actual hypervisor at some point, I'd appreciate it if you made that clear in your README.
This whole "written in Rust" as if it was a feature BS must stop someday.
Get the project 'A' features and compare with project 'B' features, the strength and weakness of programming languages will be apparent, on the features, runtime speed, bugs, etc..
Choosing a project over another just because its in a given language is not based on logical reasoning, but emotional reasoning and therefore the bad paths will get evident with time (Except of course if the language is really unsuitable to the domain, which is not the case here whether with C or Rust).
This emotional bias for me is a reason to actually look at Rust projects with suspicious if people working on it know its just another tool with some given properties and not some magical wand that will turn everything into unicorns and rainbows.
Note: this is also targeted at "why you would want to choose C over others ?" comment bellow in the same line
> This whole "written in Rust" as if it was a feature BS must stop someday.
I hope you can notice the hypocrisy when the title of this post has "written in <language>" in it but you have no qualm with it. The comment you are responding to didn't imply anything, it could have mentioned any language, try to read with a more open mind
afaik one of the reasons it is considered a feature is memory safety. i agree a better selling point would be to say "written in a memory safe language".
Rust is a langauge which exists because colleges want to churn out programmers who do have not spent the requitisre 4 years required to learn C. I really think we need some sort of licensing for programming...
Colleges should not be churning out "programmers" with skills in one language. Trade schools would be better for that.
In college I learned theory and algorithms, and was exposed to half a dozen programming languages at least. I mastered none of them, that wasn't the point.
I think it's commonly accepted that it takes less time to write memory-safe code in Rust than in C. It's also commonly accepted that for stuff where you can leverage a lots of libraries and mostly write glue code, Rust is faster than C. It's up to you to evaluate if those are your goals or not.
actually its not at all better but maybe different , libkrun is far more advanced and has a better support. Wiser is only restricted as a CLI tool as of now.
I would also set the CPU name to KVMKVMKVM and enable a few of the paravirtual devices like KVMCLOCK.
Good luck with your project!