QEMU Internals (opens in new tab)

I work on virtual machines at Google. I usually suggest "Hardware and Software Support for Virtualization" [1] to new team members without a virtualization background.

[1] https://www.amazon.com/Hardware-Software-Virtualization-Synt...

"KVM host in a few lines of code" (https://zserge.com/posts/kvm/) is a fun article to get started with.

The sibling's comment book recommendation "Hardware and Software Support for Virtualization" book is on point and it's written by one of the co-founders of VMware.

Another book on Libvirt will be handy since it is the de facto API for most virtualization including VMs and containers[1].

[1]https://www.amazon.com/Foundations-Libvirt-Development-Maint...

For a really simple emulator project (not quite the level of VirtualBox), check the "IntCode" challenges from AdventOfCode 2019.

Hardware and Software Support for Virtualization Synthesis Lectures on Computer Architecture (2017)

https://www.morganclaypool.com/doi/abs/10.2200/S00754ED1V01Y...

Bringing Virtualization to the x86 Architecture with the Original VMware Workstation (2012)

https://dl.acm.org/doi/abs/10.1145/2382553.2382554

Fuzz week shows how to make make a snapshot / resettable jitting hypervisor.

https://m.youtube.com/playlist?list=PLSkhUfcCXvqHsOy2VUxuoAf...

I've always been intrigued by virtual machines and emulation as well. I've always wanted to try and make an emulator of some kind. I don't know much about the internals of VirtualBox, but my suggestion would be to start "easy" with one CPU/Computer System/Game Console and go from there. That's what I finally did with the 6502 and Commodore 64.

That is such a bizarre viewpoint from my perspective. The absolute deathtrap that is the 737 MAX had two software-related critical failures in 400,000 flights. That constitutes a whole system per-flight software reliability of 2 in ~400,000 or a ~99.9995%, 5 9s. Obviously that is still unacceptable as that is far below the software standard amongst all commercial airplanes where software has not been implicated in a crash for at least the last 10 years except for the 737 MAX. Even if we include the two 737 MAX crashes into the statistics, the whole system per-flight software reliability of all commercial airplanes over the last decade is at least 2 in ~100,000,000 or ~99.999998% or 7 9s. The standard in airplane software is literally 5000x more reliable than AWS SLA guarantees and 500x the holy grail in server software of 5 9s. Even the 737 MAX is 20x better than the AWS guarantee and 2x more reliable than 5 9s. Airplane software is not bad, we just rightfully expect a lot from systems that lives depend on, so even systems that are better than best-in-class non-safety software are completely unacceptable which may give the impression that they are bad in absolute terms as they fail to live up to our expectations.

You seem to be taking the entire industry down by painting broad strokes from one incident; yet somehow planes aren't crashing everyday so. Anyway I don't work in the field but what I've read, issues with the 737 MAX were not software related - they were and are design related. They need redundant sensors. Their overall design approach was due to their desire not to have pilots go through additional training and the fact that they didn't have redundant sensors is criminal or a disagree alert standard were criminally negligent decisions in my opinion. Those are also largely system design related decisions; not software engineers.

Here's a quick, high level, run-down:

https://jalopnik.com/heres-everything-boeing-did-to-fix-the-...

"In practice, the MCAS system accepted readings from only a single angle of attack (AOA) sensor. In the event of a bad sensor reading, the MCAS initiated repeated nose-down inputs. The cockpit alarm for AOA disagreement was also an expensive upcharge.

So Boeing made some changes to the MAX and the MCAS system. The MCAS system now has a maximum limit of one nose-down input during a single event of high angle of attack. The limit doesn’t reset if the pilots activate the electric trim switches. Further, an AOA sensor monitor was added to make sure MCAS doesn’t use AOA input if sensors disagree with each other by more than 5.5 degrees. The Flight Control Computer itself also no longer relies on a single sensor. Another important change is with the AOA DISAGREE alert. Previously, this alert was part of an optional AOA Gauge offered by Boeing. Now the AOA DISAGREE alert is always enabled, regardless of whether the airline has the option or not. All these changes are in the FAA summary."

More detail in a Nytimes article of the flaws:

https://www.nytimes.com/interactive/2019/03/29/business/boei...

Airbus also has the Airbus Defense and Space group as well, it’s not just all airplanes :)

Is "move fast and break things" a good culture for airplane manufacturer? Airbus is known for making good software, they earned their reputation by releasing the first fly by wire airliner (a320) in 84, which forced Boeing to go this route with the 777.

Making safety critical software is a totally different world than what is seen on HN. The culture needed is safety culture and it is all about doing boring code, following strict coding rules, doing tons of documentation and analysis prior coding and a doing tons of review of tests. I don't think it will arouse interest here.

Airbus is known to be excellent in airplane software development.

However, this is probably not about the airplane part of Airbus. Like Boeing, Airbus also have huge defense and space divisions.