10:51 <marcan> how's this for a cute hypervisor: https://mrcn.st/p/1Dm3b6BQ :>

10:52 <DrWhax> hawt

10:53 <j`ey> :O

11:00 <marcan> arnd: not a gdb stub, but still quite nice :)

11:00 <marcan> you can also see/change context registers, e.g. ctx.regs[0] == x0 (and any changes are committed on return back to the guest)

11:56 <arnd> marcan: that looks pretty cool. Do you keep talking to the debug shell over usb while using the serial port for the guest console, or is both of these the serial port?

12:12 <arnd> marcan: can the hypervisor already process usb data like keyboard input over cdc-acm while the guest is running? If that works, adding drivers/tty/hvc/hvc_dcc.c earlycon support to the hypervisor should be no more than a few lines

12:13 <arnd> and that in turn would mean I could my machine without needing a serial cable first

12:14 <arnd> I just received a thunderbolt drive to install onto, as the internal drive is already full of my coworker's work stuff

13:14 <marcan> arnd: the HV goes over USB and the guest over serial right now, but the next thing i'm scheming is virtualizing serial into a secondary cdc-acm interface

13:15 <marcan> right now there are no interrupts, so the HV only processes USB data when an exception happens. I'll do something about that soon, but for a m1n1 guest or just serial prints there is no need since those are triggered by the guest

13:16 <marcan> hvc_dcc would work too, but I need this to work for macos so it makes sense to virtualize serial (and serial is easy anyway)

13:30 <arnd> right, makes sense

18:33 <marcan> arnd: re gdbstub, I'll make python implement that (so you can dual wield gdb and the python debug shell), converting to my protocol

18:33 <marcan> like gdbserver

18:36 <marcan> https://mrcn.st/p/LCVn7jMf <- basic virtual UART (output only routed into the main CDC-ACM for now, will move it to a secondary later)