Debugging Linux which is in QEMU VM

Sysprogs forums Forums VisualKernel Debugging Linux which is in QEMU VM

This topic contains 3 replies, has 2 voices, and was last updated by  support 9 months, 2 weeks ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #26784

    Goerge255
    Participant

    support wrote:

    As a workaround, unless you are debugging drivers for hardware that cannot be virtualised, please consider using VM snapshots as a way of recovering from file system corruption.

    OK, so I took your advice and put the entire target in a snapshotted QEMU VM.

    I had to choose something else than VMware and VirtualBox (VMs that VK declares support for) because they only support the x86 architectures for the guest/target systems and QEMU supports ARM, MIPS, Alpha, CRIS, LM32, M68k, MicroBlaze,  OpenRisc32, PowerPC, S/390, SH4, SPARC 32/64, Unicore32, Xtensa, x86, x86-64.

    My debugees usually run on ARM, MIPS CPUs, so I really could not have used VMware nor VirtualBox.  I am using Debian 9 or 10 compiled for these plattforms.

     

    QUESTION: How to reliably debug Debian (ARM)  running in QEMU with VisualKernel?

    I am running QEMU with the command line listed below.

    Notice that the option: hostfwd=tcp:127.0.0.1:10022-192.168.0.15:22 forwards the SSH port 10022 on the localhost (where VirtualKernel is running) to the IP address of the guest/target Debian Linux (ARM) running inside the QEMU VM. That is why VK communicates with the target via root@127.0.0.1:10022.

    Also notice, that  the option  -device virtio-net-device means that the network adapter which the guest/target Debian sees and talks to, is a virtio adapter.

    Do I need to forward  any other ports to get the debugging working with QEMU or must I play with virtual UART ports, or something else entirely ?

     

    qemu-system-arm -M virt
    -m 1024
    -kernel vmlinuz-4.19.0-6-armmp-lpae
    -initrd initrd.img-4.19.0-6-armmp-lpae
    -append root=/dev/vda2
    -drive if=none,file=hda.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd
    -netdev user,id=mynet,restrict=off,net=192.168.0.0/24,hostfwd=tcp:127.0.0.1:10022-192.168.0.15:22 -device virtio-net-device,netdev=mynet
    -nographic
    -no-reboot

     

    • This topic was modified 9 months, 2 weeks ago by  Goerge255.
    #26785

    support
    Keymaster

    Sorry, we absolutely do not support Qemu. It is extremely unreliable and difficult to configure. Please try using VMWare instead.

    #26787

    Goerge255
    Participant

    Please try using VMWare instead.

    But how ?

    VMware does not support ARM nor MIPS CPUs !!!

    • This reply was modified 9 months, 2 weeks ago by  Goerge255.
    #26791

    support
    Keymaster

    Thanks for clarifying this. In that case, indeed QEmu could one of the best bets, although configuring it would be non-trivial.

    Generally, Qemu supports the gdb stub mode similar to VWMare, so we would advise the following configuration:

    • Forward SSH port from the target to 10022 or any other port and specify “localhost:10022”  as the host name in VisualKernel.
    • Enable the gdb stub mode in Qemu and use the “custom” mode in VisualKernel, directing it to connect to the specified host/port.

    That said, due to low reliability of Qemu, this setup may trigger strange bugs, or not work at all.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.