oak
oak copied to clipboard
project-oak
Improve debugging under crosvm
The main use case left for qemu that we have is that debugging with qemu works (according to @conradgrobler if you try to set a breakpoint when attached to crosvm, our unikernel double faults and dies).
It's most likely we need to add a few more interrupt handles (in particular for debug and breakpoint) in a way that works with GDB-s expectations.
Actually the gdbstub crate is bit of a red herring, I think: that's already included in crosvm. Not sure what's needed in the guest side for things to work, thoug.
It seems that support for software breakpoints is not yet fully implemented in crosvm and it relies on a gdb feature to inject these: https://chromium.googlesource.com/chromiumos/platform/crosvm/+/refs/heads/main/src/crosvm/gdb.rs#165
Reading the suggested documentation (https://docs.rs/gdbstub/0.6.2/gdbstub/target/trait.Target.html#method.guard_rail_implicit_sw_breakpoints) I think this means that we need to implement a debug exception handler to coordinate debugging between the hypervisor and guest.
Rephrasing to make sure I follow: Crosvm handles debugging by injecting breakpoint instructions into the client via said gdb feature. We currently don't handle these, and so we fail. If we implement handlers, we wouldn't fail.
Questions: What specifically would these handlers need to do? How would they do it? Question: Debugging works in qemu, why is that? Does qemu offer support for "outside" breakpoints in a way crosvm doesn't?
Rephrasing to make sure I follow: Crosvm handles debugging by injecting breakpoint instructions into the client via said gdb feature. We currently don't handle these, and so we fail. If we implement handlers, we wouldn't fail.
Crosvm does not inject it as far as I understand, but relies on gdb to inject these instructions into the execution stream or the client.
Questions: What specifically would these handlers need to do? How would they do it?
I don't know yet. This requires additional investigation, but I would guess that we might have to set the value of some debug registers before continuing. At there very least there should be a handler so that the interrupt does not trigger a double-fault. We could start with just logging some simple information, similar to https://os.phil-opp.com/cpu-exceptions/#implementation.
Question: Debugging works in qemu, why is that? Does qemu offer support for "outside" breakpoints in a way crosvm doesn't?
I assume this is because qemu implements software breakpoints fully, rather than relying on gdb to inject these instructions.