Wednesday, December 28, 2011

QEMU Networking

Summary:

{/etc/qemu-ifup}
#!/bin/sh
#switch=$(/sbin/ip route list | awk '/^default / { print $5 }') -- error/remove
switch=virbr0 -- correct
/sbin/ifconfig $1 0.0.0.0 up -- keep
/usr/sbin/brctl addif ${switch} $1 -- keep

{/etc/qemu-ifdown}
#!/bin/sh
#switch=$(/sbin/ip route list | awk '/^default / { print $5 }') -- error/remove
swtich=virbr0 -- correct
/usr/sbin/brctl delif $switch $1 -- keep
/sbin/ifconfig $1 0.0.0.0 down -- keep

add these parameters to qemu: -net nic,vlan=0 -net tap,vlan=0

Previous Writing:
Write 2 network scripts as below: ( don't forget the chmod +x on each file. )

[root@sitedesign ~]# cat /etc/qemu-ifdown
#!/bin/sh
/sbin/ifconfig virbr0 down
/sbin/ifconfig down $1
/sbin/ifup eth0

[root@sitedesign ~]# cat /etc/qemu-ifup
#!/bin/sh
/sbin/ifconfig $1 0.0.0.0 promisc up
/usr/sbin/brctl addif virbr0 $1

Then to start the VM:

as root:
#~> qemu-kvm -net nic,vlan=0 -net,tap,vlan=0 -hda winxp.img -hdb winxp_disk2.img -usb -usbdevice tablet -localtime -daemonize
That should start you up with a connection to the default virbr that gets made by fedora at boot time.

(original link)

using CSCOPE

1. build database: cscope -b -q -k -R
2. invoke: cscope -d ... does not create the database again

3: invoke command line:
      find all functions that calls bad_page()
          cscope -d -3 bad_page -L
      find all functions that bad_page() calls
          cscope -d -2 bad_page -L

exit: ctrl_d




Friday, December 16, 2011

Using QEMU for Direct Debugging (INCOMPLETE)

Install kvm-pxe first

kernel build: two places
     inside the vm
     in in the host

make initrd inside vm, copy it to host in the qemu disk directory
copy vmlinux, sysmap and config into qemu disk directory

then run the kernel:
qemu -smp 4 -m 384 -hda ubswapper.img -kernel vmlinuz-2.6.38.2 -initrd initrd.img-2.6.38.2 "console=ttyS0,115200n8 root=/dev/sda1 text" -serial stdio > trace


Friday, December 9, 2011

Tracing In Brief

cd /sys/kernel/debug/tracing

# viewing functions
functions are listed in available_filter_function
grep shrink available_filter_function

# viewing tracers
cat available_tracers
function_graph, function are important

# setting function and graph
root@musfiq-Dell-DM051:/sys/kernel/debug/tracing# echo shrink_zone > set_ftrace_filter
root@musfiq-Dell-DM051:/sys/kernel/debug/tracing# echo shrink_zone > set_graph_function

# set tracer
root@musfiq-Dell-DM051:/sys/kernel/debug/tracing# echo function_graph > current_tracer
root@musfiq-Dell-DM051:/sys/kernel/debug/tracing# echo 1 > tracing_on

root@musfiq-Dell-DM051:/sys/kernel/debug/tracing# echo 0 > tracing_on

Thursday, December 8, 2011

Console Over Serial

in kvm, add another serial connection
in kernel boot parameters, add: console=ttyS1
now, all kernel messages will be redirected to ttyS1
if kgdboc=ttyS0, then run gdb on that port.
that's it!

so, now you can debug kernel on one serial port while get the kernel messages on another serial port.


Thursday, October 20, 2011

Remote Kernel Compilation: Custom Installation Path

make a directory myinstall

#> make modules_install INSTALL_MOD_PATH=myinstall
#> make install INSTALL_PATH=myinstall
#> make headers_install INSTALL_HDR_PATH=myinstall

everything will be neatly under myinstall directory :-)

now make the ramdisk by
mkinitramfs -o initrd.img-3.1.6 -r (myinstall) -v 3.1.6

on the remote machine,
copy myinstall/lib into /lib and fix the build and source symbolic links to actual source code directory. if there is no source directory, then only copy the headers. into /lib/modules/<version>/build/include...

/lib/modules/<version>/kernel contains all the .ko files
/lib/modules/<version>/build and source points to the headers, or you can keep the actual source files here... all it cares is the include directory inside build :-)

copy myinstall/config, map and vmlinuz into /boot and configure grub.

that's how we transfer a kernel from remote machine to target machine. do not forget to copy the .config file from target to remote before building kernel on remote.

Saturday, October 15, 2011

Breakpoints in modules

I am working in modframe

Inside Host, connect gdb via pts to VM. 

Inside VM,
put the module in /root/Desktop/modexperiments/mf
make the module with all debugging info
    add this line in Makefile... EXTRA_CFLAGS += -ggdb3
modframe.ko will be created

insert the module. then it will have a /sys/modules/modframe/sections/.text entry.
track that 0xf8031000
or try this
grep function_name /proc/kallsyms ... track that address

Inside Host,

copy mf directory into /root/Desktop/modexperiments/ ... so that the files are there.

Now we will add breakpoints. 

Inside VM,

echo g > /proc/sysrq-trigger
This will hand transfer to gdb in host

Inside Host,
fire up gdb in host,
  # add-symbol-file modframe.ko 0x########
               -s .data 0x########
               -s .bss   0x########
you can view listing, or put a break point b *0xf8031000

Inside VM,
or remove the modules... that will hit the breakpoint :)
Other interesting utilities
objdump is another utility (use -h flag)

 $ nm modframe.ko -- view symbols 
 
or
 
 $ objdump -t modframe.ko            (all sections)
 $ objdump -t -j data modframe.ko    (data section)
 $ objdump -t -j bss modframe.ko     (BSS section)  
   
Ref:
 
https://www.linux.com/learn/linux-career-center/33991-the-kernel-newbie-corner-
kernel-and-module-debugging-with-gdb 

http://linux-hacks.blogspot.com/2009/07/using-gdb-for-debugging-kernel-modules.html