use of serial port crashes VM w/ non-mainstream OS

[Ralph Schmieder]

I try to run a Cisco router VM based on x86 known as IOSv (virtual IOS). The same image works perfectly fine with KVM and VMware Fusion / Workstation / ESXi. It also works OK in VB as long as there is no serial port connected. However, the serial console is the only way to access the box (assuming it does not have a configuration which also would allow to SSH / Telnet into the VM / router).

When starting up the VM in VB it displays the Grub boot loader and then, in 9 out of 10 cases, instantly displays a Guru meditation instead of loading the kernel image. This is regardless of using a Pipe, a TCP port or a raw file for the port. Haven't tried host device as that's useless for our use case. If the port is enabled but 'disconnected' then the VM comes up fine all the time.

This was tested on a Mac (MacBook Pro Mid2017, Intel Core i7) with

• VB 5.1.30
• VB 5.0.40
• VB 5.2.2

I also ran into this problem on Linux. Here I run VB in a nested VM running on KVM on an Intel i7 w/ host-passthrough and 5.0.40 on Ubuntu Xenial... It seems to work more often there (more than 1 in 10) but also produces the Guru meditation when trying often enough.

[Ralph Schmieder]

VM log w/ guru meditation when using serial port

[Ralph Schmieder]

Further experimenting w/ the VM on 5.0.40 inside of Linux shows that it seems to reliably boot every time. However, when rebooting the VM after a successful boot from inside the VM (e.g. issuing a "reload" command) it also always shows a Guru Meditation. strace log is ~23MB in size (zipped). I could also link to a screen recording showing the procedure, if that is of help.

[Socratis]

Related discussion in the forums: ​https://forums.virtualbox.org/viewtopic.php?f=4&t=85534

[aeichner]

The guest triple faults which causes the Guru Meditation (on real hardware the system would reset). The triple fault is something caused by the guest which might be caused by the serial port emulation being in a state not expectd by the guest but without the guest in question there is nothing we can do to debug this issue further.

[Ralph Schmieder]

So, what's the recommended way going forward? would an strace help? Access to a system that has the vm disk installed? a copy of the VM? As stated, it's not entirely broken since

• it works ~ 1 in 10-20 times
• it works on other hypervisors

[aeichner]

Since this is a Cisco based VM an official way to download the VM image/installation media would be great to not run into any legal trouble. I don't mind setting up the VM myself if required.

[Ralph Schmieder]

Looks like we masked the issue by removing the first console output which happened right after the image is loaded. This might also explain why sometimes it worked and most of the time it doesn’t. Accessing the serial line before it has been fully initialized may lead to the crash and delaying the output is a potential workaround.

[aeichner]

So this means it could be a bug in the guest causing the triple fault and this might happen on real hardware too? A real system would just reset itself but VirtualBox defaults to throwing a guru meditation so we can inspect the guest state to see what caused the triple fault.

[Ralph Schmieder]

Wondering: Is it possible to access a hardware resource / io register 'too early' with real hardware and causing a system reset? Need to sync with the s/w engineer and see what actually is done in initializing the hardware before the output of the 'booting ios' string. Will report back

[mmen]

The console output line was a blocking writing to the COM1 port at 0x3F8. It seems that the guest was in a spin loop waiting for the serial port to ack the transmission of the char. If we changed this to a non-blocking writing then we won't hit the triple fault and Guru Meditation. But the characters would be spoofed out at random places mixed with other console output printed later on.

Another observation is that this console output was at the very early stage of the guest boot up, the first thing of entering the guest OS scope right after the grub menu is gone, before the guest is trying to detect the memory and the arguments passed by grub. We tried adding a blocking writing at later stage and it worked fine.

The issue was not seen on real hardware (as on the real hardware, the OS does not interact with grub command line) or other hypervisors (KVM, ESXi, etc).

[mmen]

Knock! Knock!! Any comments from the experts?