Live data from Hacker News

QEMU Internals

airbus-seclab.github.io

31–36 of 36 posts

Re: QEMU Internals

#31
post #12
post #2

Thank you. On the same subject can someone recommend a book or any other resource to learn about virtual machine internals? My goal is to try to build a toy clone of VirtualBox/VMWare. So far I have found one -- Virtual Machines by James E. Smith and Ravi Nair.

Fuzz week shows how to make make a snapshot / resettable jitting hypervisor. https://m.youtube.com/playlist?list=PLSkhUfcCXvqHsOy2VUxuoAf...

9 lectures for a total of 59+ hours! Wow. Commitment required.

Re: QEMU Internals

#32
post #2

Thank you. On the same subject can someone recommend a book or any other resource to learn about virtual machine internals? My goal is to try to build a toy clone of VirtualBox/VMWare. So far I have found one -- Virtual Machines by James E. Smith and Ravi Nair.

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

I believe this is the direct link to the mentioned challenges: https://adventofcode.com/2019

Re: QEMU Internals

#33

I don't mean this to disparage Airbus in any way but after Boeing's issues with the 737 MAX I'd assumed a fairly poor culture of software at airplane manufacturers in general. Super glad to see work like this coming out of Airbus, really makes me rethink my earlier assumptions about software competence in the field.

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...

Re: QEMU Internals

#34
post #31
post #12

Earlier quoted context omitted.

Fuzz week shows how to make make a snapshot / resettable jitting hypervisor. https://m.youtube.com/playlist?list=PLSkhUfcCXvqHsOy2VUxuoAf...

9 lectures for a total of 59+ hours! Wow. Commitment required.

Yea, it's streaming so there are some debugging sessions in there, but the information is gold.

Re: QEMU Internals

#35
post #16

Earlier quoted context omitted.

I built about a third of a NES emulator. The nesdev wiki is mostly decent, although there's a fair number of things where it seems like the first people to figure things out got stuff kind of backwards, and if you flip it, it's a lot easier, that's the sort of fighting the specifications I think you're talking about. All that said, emulating the CPU was pretty fun. There's a CPU test rom out there you can run with tr…

I did a GameBoy and similarly found the CPU enjoyable and the PPU a huge pain. Perhaps if I understood graphics better, I would have enjoyed it more, but like you say it just felt like a lot of steps.

I don't know if the GameBoy PPU has the background vs foreground split. The background processing was pretty reasonable, and once you got it kind of working, it was fun to debug and get it actually working. My favorite thing was when I was processing everything in the wrong order so the menu of the rom I was using to test had all the words backwards.

But the foreground / object sprites have this huge pipeline. IIRC, the PPU determines which sprites to draw in line X + 1 during line X. After that, it has to load the data for each object, etc etc. It was just discouraging. Plus since my frame rate is so low, I have to sit at a blank screen for quite some time waiting for the game to show anything, and longer for the demo to start (I don't have controls)...

Anyhow, glad I'm not alone ;)

Re: QEMU Internals

#36
post #29

Earlier quoted context omitted.

This looks like a good read, thanks. I'm curious what your background is. How does one go about getting into that specialty at an org like Google? I've understood that Borg and GKE containers at Google generally always run in a VM. Is this where your work is(platform) or are you more research oriented?

Generally "systems-y software" is my background. I joined Google for a semi-experimental operating system project and from there it was a small jump to virtualization when I decided I was interested in doing something else. I'm definitely on the platform side, but been doing some interesting stuff recently :)

> semi-experimental operating system project

Fuchsia? :)

Post reply on HN