Running in KVM

Setup

If you have a CPU with hardware virtualization support you can run JNode in kvm wich is much faster than vmware-[player|server] (at least for me). You need a CPU that either supports Intel's IVT (aka Vanderpool) or AMD's AMD-V (aka Pacifica).

With

egrep '^flags.*(vmx|svm)' /proc/cpuinfo"

you can easily check if your CPU supports VT or not. If you receive output your CPU is supported, else it is not. If your CPU is supported also check that VT is enabled in your system bios.

Load the kvm modules matching your CPU, either "modprobe kvm_intel" or "modprobe kvm_amd", install kvm user tools and setup permissions so users may run kvm (Have a look at a HOWTO for your distro for details: Ubuntu, Gentoo).

Once you have setup everything you can start kvm from the commandline (I think there are GUI frontends too, but I'm using the command line). You should be carefull though, acpi in JNode seems to kill kvm, so allways disable acpi. I also had to deactivate the kvm-irqchip as it trashed JNode. The command that works for me is:

kvm -m 768 -cdrom jnode-x86-lite.iso -no-acpi -no-kvm-irqchip -serial stdout -net none -std-vga

The "-serial" switch is optional but I need it for kdb (kernel debugger). If you want to use the Vesa mode of JNode you should also use "-std-vga", overwise you will not have a vesa mode. Set the memory whatever you like (768MB is my default).

Things that still need to be tested:

  • "-drive/-hda/.." allow to supply harddisks, test if this works too
  • "-smp n" allows to give n cores to kvm (difficult as JNode is not SMP safe atm)
  • "-audio/soundhw" allows sound emulation
  • test "-usb/.."
  • Test network. Atm I'm missing some kernel modules so I deactivated network for the moment.
  • Test gdb with kvm. This should be more fun than using qemu Smiling
  • Test other CPUs, especially the qemu64 (i.e. 64bit CPU) support once JNode's 64bit version works again
  • various options for serial line

    Instead of the "-serial stdout" option, which only allow to output message, you can use :
    "-serial tcp::telnet-port,server", where telnet-port is a port number of your choice (I am using 4447).
    With that option, kvm will run a telnet server. Then, you can do "telnet 192.168.44.2 telnet-port" to receive messages from the virtual serial port
    and also send commands to jnode's kernel debugger. Here 192.168.44.2 is the IP address of the vm ran by kvm : you will have to find what's the IP address in your case.

    Fabien

    my blog : en français, in english or both

    KVM with gdb

    I tested the kvm's gdb interface. If you supply "-s" to the kvm command line kvm will open a port to "remotely" debug the guest operating system. If you additionally supply "-S" the CPU will be halted right after poweron until a gdb process connects.

     $ kvm -S -s -m 768 ...
    

    Once the virtual mashine is powered on you can connect gdb to it. Start gdb and connect to the remote host:

     $ gdb
    GNU gdb 6.7.1
    Copyright (C) 2007 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later 
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-pc-linux-gnu".
    (gdb) target remote :1234
    

    This connects you to the kvm's guest. To run kvm type

    (gdb) continue
    

    I tested a bit to set breakpoints, but I'm totaly unused to gdb and I wasn't able to make a single breakpoint work. I tried some code that crashed JNode. Usefull commands I found in this regard were

    (gdb) info reg
    

    to display a register dump (should show the same values a kernel panic shows you Eye-wink),

    (gdb) x/10i $eip
    

    to display the next 10 instructions (in readable asm code) starting from the address in EIP (Instruction pointer). Using "x/10b" you can display the data in 1byte steps, "x/10h" for 2byte, "x/10w" for 4bytes or "x/10g" for 8byte values. Look at any gdb documentation/tutorial/howto for additional infos. Btw, you will not be able to display stacktraces, methods, classes,.. as gdb does not know about them. I don't know how this works, but we're at least missing symbol tables and I guess we also have a stacklayout different from C's.
    I'd be happy if someone with more knowledge about gdb and debugging than me could have a look at it too.