[PATCH] KVM: Add wrapper script around Qemu to test kernels

[PATCH] KVM: Add wrapper script around Qemu to test kernels

[Alexander Graf]

On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
would be doing and what he expects from it. Basically he wants a
small and simple tool he and other developers can run to try out and
see if the kernel they just built actually works.

Fortunately, Qemu can do that today already! The only piece that was
missing was the "simple" piece of the equation, so here is a script
that wraps around Qemu and executes a kernel you just built.

If you do have KVM around and are not cross-compiling, it will use
KVM. But if you don't, you can still fall back to emulation mode and
at least check if your kernel still does what you expect. I only
implemented support for s390x and ppc there, but it's easily extensible
to more platforms, as Qemu can emulate (and virtualize) pretty much
any platform out there.

If you don't have qemu installed, please do so before using this script. Your
distro should provide a package for it (might even call it "kvm"). If not,
just compile it from source - it's not hard!

To quickly get going, just execute the following as user:

    $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash

This will drop you into a shell on your rootfs.

Happy hacking!

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 Documentation/run-qemu.sh |  284 +++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 284 insertions(+), 0 deletions(-)
 create mode 100755 Documentation/run-qemu.sh

diff --git a/Documentation/run-qemu.sh b/Documentation/run-qemu.sh
new file mode 100755
index 0000000..0bac924
--- /dev/null
+++ b/Documentation/run-qemu.sh
@@ -0,0 +1,284 @@
+#!/bin/bash
+#
+# QEMU Launcher
+#
+# This script enables simple use of the KVM and Qemu tool stack for
+# easy kernel testing. It allows to pass either a host directory to
+# the guest or a disk image. Example usage:
+#
+# Run the host root fs inside a VM:
+#
+# $ ./Documentation/run-qemu.sh -r /
+#
+# Run the same with SDL:
+#
+# $ ./Documentation/run-qemu.sh -r / --sdl
+# 
+# Or with a PPC build:
+#
+# $ ARCH=ppc ./Documentation/run-qemu.sh -r /
+# 
+#
+
+USE_SDL=
+USE_VNC=
+KERNEL_BIN=arch/x86/boot/bzImage
+MON_STDIO=
+KERNEL_APPEND2=
+SERIAL=ttyS0
+SERIAL_KCONFIG=SERIAL_8250
+
+function usage() {
+	echo "
+Run-Qemu allows you to execute a virtual machine with the Linux kernel
+that you just built. To only execute a simple VM, you can just run it
+on your root fs with \"-r / -a init=/bin/bash\"
+
+	-a, --append parameters
+		Append the given parameters to the kernel command line
+
+	-d, --disk image
+		Add the image file as disk into the VM
+
+	-r, --root directory
+		Use the specified directory as root directory inside the guest.
+
+	-s, --sdl
+		Enable SDL graphical output.
+
+	-S, --smp cpus
+		Set number of virtual CPUs
+
+	-v, --vnc
+		Enable VNC graphical output.
+
+Examples:
+
+	Run the host root fs inside a VM:
+	$ ./Documentation/run-qemu.sh -r /
+
+	Run the same with SDL:
+	$ ./Documentation/run-qemu.sh -r / --sdl
+	
+	Or with a PPC build:
+	$ ARCH=ppc ./Documentation/run-qemu.sh -r /
+"
+}
+
+function require_config() {
+	if [ "$(grep CONFIG_$1=y .config)" ]; then
+		return
+	fi
+
+	echo "You need to enable CONFIG_$1 for run-qemu to work properly"
+	exit 1
+}
+
+function has_config() {
+	grep "CONFIG_$1=y" .config
+}
+
+function drive_if() {
+	if [ "$(has_config VIRTIO_BLK)" ]; then
+		echo virtio
+	elif [ "$(has_config ATA_PIIX)" ]; then
+		echo ide
+	else
+		echo "\
+Your kernel must have either VIRTIO_BLK or ATA_PIIX
+enabled for block device assignment" >&2
+		exit 1
+	fi
+}
+
+GETOPT=`getopt -o a:d:hr:sS:v --long append,disk:,help,root:,sdl,smp:,vnc \
+	-n "$(basename \"$0\")" -- "$@"`
+
+if [ $? != 0 ]; then
+	echo "Terminating..." >&2
+	exit 1
+fi
+
+eval set -- "$GETOPT"
+
+while true; do
+	case "$1" in
+	-a|--append)
+		KERNEL_APPEND2="$2"
+		shift 2
+		;;
+	-d|--disk)
+		QEMU_OPTIONS="$QEMU_OPTIONS -drive \
+			file=$2,if=$(drive_if),cache=unsafe"
+		USE_DISK=1
+		shift 2
+		;;
+	-h|--help)
+		usage
+		exit 0
+		;;
+	-r|--root)
+		ROOTFS="$2"
+		shift 2
+		;;
+	-s|--sdl)
+		USE_SDL=1
+		shift
+		;;
+	-S|--smp)
+		SMP="$2"
+		shift 2
+		;;
+	-v|--vnc)
+		USE_VNC=1
+		shift
+		;;
+	--)
+		shift
+		break
+		;;
+	*)
+		echo "Could not parse option: $1" >&2
+		exit 1
+		;;
+	esac
+done
+
+if [ ! "$ROOTFS" -a ! "$USE_DISK" ]; then
+	echo "\
+Error: Please specify at least -r or -d with a target \
+FS to run off of" >&2
+	exit 1
+fi
+
+# Try to find the KVM accelerated Qemu binary
+
+[ "$ARCH" ] || ARCH=$(uname -m)
+case $ARCH in
+i*86|x86_64)
+	KERNEL_BIN=arch/x86/boot/bzImage
+	# SUSE and Red Hat call the binary qemu-kvm
+	[ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null)
+
+	# Debian and Gentoo call it kvm
+	[ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null)
+
+	# Qemu's own build system calls it qemu-system-x86_64
+	[ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-x86_64 2>/dev/null)
+
+	# i386 version of Qemu
+	if [ ! "$(has_config X86_64)" ]; then
+		[ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu 2>/dev/null)
+	fi
+	;;
+s390*)
+	KERNEL_BIN=arch/s390/boot/image
+	[ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-s390x 2>/dev/null)
+	;;
+ppc*)
+	KERNEL_BIN=vmlinux
+
+	IS_64BIT=
+	[ "$(has_config PPC64)" ] && IS_64BIT=64
+	if [ "$(has_config PPC_85xx)" ]; then
+		QEMU_OPTIONS="$QEMU_OPTIONS -M mpc8544ds"
+	elif [ "$(has_config PPC_PSERIES)" ]; then
+		QEMU_OPTIONS="$QEMU_OPTIONS -M pseries"
+		SERIAL=hvc0
+		SERIAL_KCONFIG=HVC_CONSOLE
+	elif [ "$(has_config PPC_PMAC)" ]; then
+		[ "$(has_config SERIAL_PMACZILOG_TTYS)" ] || SERIAL=ttyPZ0
+		SERIAL_KCONFIG=SERIAL_PMACZILOG
+	else
+		echo "Unknown PPC board" >&2
+		exit 1
+	fi
+
+	[ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-ppc${IS_64BIT} 2>/dev/null)
+	;;
+esac
+
+if [ ! "$QEMU_BIN" ]; then
+	echo "\
+Could not find a usable Qemu binary. Please install one from \
+your distro or from source code." >&2
+	exit 1
+fi
+
+# The binaries without kvm in their name can be too old to support KVM, so
+# check for that before the user gets confused
+if [ ! "$(echo $QEMU_BIN | grep kvm)" -a \
+     ! "$($QEMU_BIN --help | egrep '^-machine')" ]; then
+	echo "Your Qemu binary is too old, please update to at least 0.15." >&2
+	exit 1
+fi
+QEMU_OPTIONS="$QEMU_OPTIONS -machine accel=kvm:tcg"
+
+# We need to check some .config variables to make sure we actually work
+# on the respective kernel.
+if [ ! -e .config ]; then
+	echo "\
+Please run this script on a fully compiled and configured
+Linux kernel build directory" >&2
+	exit 1
+fi
+
+if [ ! -e "$KERNEL_BIN" ]; then
+	echo "Could not find kernel binary: $KERNEL_BIN" >&2
+	exit 1
+fi
+
+QEMU_OPTIONS="$QEMU_OPTIONS -kernel $KERNEL_BIN"
+
+if [ "$USE_SDL" ]; then
+	# SDL is the default, so nothing to do
+	:
+elif [ "$USE_VNC" ]; then
+	QEMU_OPTIONS="$QEMU_OPTIONS -vnc :5"
+else
+	# When emulating a serial console, tell the kernel to use it as well
+	QEMU_OPTIONS="$QEMU_OPTIONS -nographic"
+	KERNEL_APPEND="$KERNEL_APPEND console=$SERIAL earlyprintk=serial"
+	MON_STDIO=1
+	require_config "$SERIAL_KCONFIG"
+fi
+
+if [ "$ROOTFS" ]; then
+	# Using rootfs with 9p
+	require_config "NET_9P_VIRTIO"
+	KERNEL_APPEND="$KERNEL_APPEND \
+root=/dev/root rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p"
+
+#Usage: -virtfs fstype,path=/share_path/,security_model=[mapped|passthrough|none],mount_tag=tag.
+
+
+	QEMU_OPTIONS="$QEMU_OPTIONS \
+-virtfs local,id=root,path=$ROOTFS,mount_tag=root,security_model=passthrough \
+-device virtio-9p-pci,fsdev=root,mount_tag=/dev/root"
+fi
+
+[ "$SMP" ] || SMP=1
+
+# User append args come last
+KERNEL_APPEND="$KERNEL_APPEND $KERNEL_APPEND2"
+
+############### Execution #################
+
+echo "
+	################# Linux Qemu launcher #################
+
+This script executes your currently built Linux kernel using Qemu. If KVM is
+available, it will also use KVM for fast virtualization of your guest.
+
+The intent is to make it very easy to run your kernel. If you need to do more
+advanced things, such as passing through real devices, please take the command
+line shown below and modify it to your needs. This tool is for simplicity, not
+world dominating functionality coverage.
+"
+echo "\
+Your guest is bound to the current foreground shell. To quit the guest,
+please use Ctrl-A x"
+echo "  Executing: $QEMU_BIN $QEMU_OPTIONS -append \"$KERNEL_APPEND\" -smp $SMP"
+echo
+
+exec $QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND -smp $SMP"
-- 
1.6.0.2

Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Pekka Enberg]

On Wed, Aug 24, 2011 at 1:16 AM, Alexander Graf <agraf@suse.de> wrote:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just built actually works.
>
> Fortunately, Qemu can do that today already! The only piece that was
> missing was the "simple" piece of the equation, so here is a script
> that wraps around Qemu and executes a kernel you just built.
>
> If you do have KVM around and are not cross-compiling, it will use
> KVM. But if you don't, you can still fall back to emulation mode and
> at least check if your kernel still does what you expect. I only
> implemented support for s390x and ppc there, but it's easily extensible
> to more platforms, as Qemu can emulate (and virtualize) pretty much
> any platform out there.
>
> If you don't have qemu installed, please do so before using this script. Your
> distro should provide a package for it (might even call it "kvm"). If not,
> just compile it from source - it's not hard!
>
> To quickly get going, just execute the following as user:
>
>    $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>
> This will drop you into a shell on your rootfs.
>
> Happy hacking!

It's nice to see such an honest attempt at improving QEMU usability, Alexander!

One comment: in my experience, having shell scripts under
Documentation reduces the likelihood that people actually discover
them so you might want to consider putting it under scripts or tools.

                        Pekka

Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Américo Wang]

On Wed, Aug 24, 2011 at 1:19 PM, Pekka Enberg <penberg@kernel.org> wrote:
>
> It's nice to see such an honest attempt at improving QEMU usability, Alexander!
>
> One comment: in my experience, having shell scripts under
> Documentation reduces the likelihood that people actually discover
> them so you might want to consider putting it under scripts or tools.
>

I was going to give the same suggestion, +1 for tools/ directory.

Thanks!

Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Avi Kivity]

On 08/24/2011 01:16 AM, Alexander Graf wrote:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just built actually works.
>
> Fortunately, Qemu can do that today already! The only piece that was
> missing was the "simple" piece of the equation, so here is a script
> that wraps around Qemu and executes a kernel you just built.
>
> If you do have KVM around and are not cross-compiling, it will use
> KVM. But if you don't, you can still fall back to emulation mode and
> at least check if your kernel still does what you expect. I only
> implemented support for s390x and ppc there, but it's easily extensible
> to more platforms, as Qemu can emulate (and virtualize) pretty much
> any platform out there.
>
> If you don't have qemu installed, please do so before using this script. Your
> distro should provide a package for it (might even call it "kvm"). If not,
> just compile it from source - it's not hard!
>
> To quickly get going, just execute the following as user:
>
>      $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>
> This will drop you into a shell on your rootfs.
>
> Happy hacking!
>
> +
> +function has_config() {
> +	grep "CONFIG_$1=y" .config
> +}

grep -q ?

> +	case "$1" in
> +	-a|--append)
> +		KERNEL_APPEND2="$2"

Might want to append to KERNEL_APPEND2, so you could have multiple -a args.

> +echo "
> +	################# Linux Qemu launcher #################
> +
> +This script executes your currently built Linux kernel using Qemu. If KVM is
> +available, it will also use KVM for fast virtualization of your guest.
> +
> +The intent is to make it very easy to run your kernel. If you need to do more
> +advanced things, such as passing through real devices, please take the command
> +line shown below and modify it to your needs. This tool is for simplicity, not
> +world dominating functionality coverage.

Device assignment could be useful for driver developers, yes.

> +"
> +echo "\
> +Your guest is bound to the current foreground shell. To quit the guest,
> +please use Ctrl-A x"
> +echo "  Executing: $QEMU_BIN $QEMU_OPTIONS -append \"$KERNEL_APPEND\" -smp $SMP"
> +echo
> +
> +exec $QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND -smp $SMP"

Would be nice to support launching gdb in a separate terminal with 
vmlinux already loaded, and already attached to qemu.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Jan Kiszka]

On 2011-08-24 10:25, Avi Kivity wrote:
> On 08/24/2011 01:16 AM, Alexander Graf wrote:
>> +"
>> +echo "\
>> +Your guest is bound to the current foreground shell. To quit the guest,
>> +please use Ctrl-A x"
>> +echo "  Executing: $QEMU_BIN $QEMU_OPTIONS -append \"$KERNEL_APPEND\"
>> -smp $SMP"
>> +echo
>> +
>> +exec $QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND -smp $SMP"
> 
> Would be nice to support launching gdb in a separate terminal with
> vmlinux already loaded, and already attached to qemu.

+ loading a python script into gdb to pull in module symbols. There are
a few implementations floating around (including my own one).

It would also be nice if one could append QEMU (note the capitalization
BTW) options to the script, maybe everything after a '--' separator.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Blue Swirl]

On Tue, Aug 23, 2011 at 10:16 PM, Alexander Graf <agraf@suse.de> wrote:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just built actually works.
>
> Fortunately, Qemu can do that today already! The only piece that was
> missing was the "simple" piece of the equation, so here is a script
> that wraps around Qemu and executes a kernel you just built.
>
> If you do have KVM around and are not cross-compiling, it will use
> KVM. But if you don't, you can still fall back to emulation mode and
> at least check if your kernel still does what you expect. I only
> implemented support for s390x and ppc there, but it's easily extensible
> to more platforms, as Qemu can emulate (and virtualize) pretty much
> any platform out there.
>
> If you don't have qemu installed, please do so before using this script. Your
> distro should provide a package for it (might even call it "kvm"). If not,
> just compile it from source - it's not hard!
>
> To quickly get going, just execute the following as user:
>
>    $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>
> This will drop you into a shell on your rootfs.
>
> Happy hacking!
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  Documentation/run-qemu.sh |  284 +++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 284 insertions(+), 0 deletions(-)
>  create mode 100755 Documentation/run-qemu.sh
>
> diff --git a/Documentation/run-qemu.sh b/Documentation/run-qemu.sh
> new file mode 100755
> index 0000000..0bac924
> --- /dev/null
> +++ b/Documentation/run-qemu.sh
> @@ -0,0 +1,284 @@
> +#!/bin/bash
> +#
> +# QEMU Launcher
> +#
> +# This script enables simple use of the KVM and Qemu tool stack for

QEMU

> +# easy kernel testing. It allows to pass either a host directory to
> +# the guest or a disk image. Example usage:
> +#
> +# Run the host root fs inside a VM:
> +#
> +# $ ./Documentation/run-qemu.sh -r /
> +#
> +# Run the same with SDL:
> +#
> +# $ ./Documentation/run-qemu.sh -r / --sdl
> +#
> +# Or with a PPC build:
> +#
> +# $ ARCH=ppc ./Documentation/run-qemu.sh -r /
> +#
> +#
> +
> +USE_SDL=
> +USE_VNC=
> +KERNEL_BIN=arch/x86/boot/bzImage
> +MON_STDIO=
> +KERNEL_APPEND2=
> +SERIAL=ttyS0
> +SERIAL_KCONFIG=SERIAL_8250
> +
> +function usage() {
> +       echo "
> +Run-Qemu allows you to execute a virtual machine with the Linux kernel

run-qemu.sh or $0

> +that you just built. To only execute a simple VM, you can just run it
> +on your root fs with \"-r / -a init=/bin/bash\"
> +
> +       -a, --append parameters
> +               Append the given parameters to the kernel command line
> +
> +       -d, --disk image
> +               Add the image file as disk into the VM
> +
> +       -r, --root directory
> +               Use the specified directory as root directory inside the guest.
> +
> +       -s, --sdl
> +               Enable SDL graphical output.
> +
> +       -S, --smp cpus
> +               Set number of virtual CPUs
> +
> +       -v, --vnc
> +               Enable VNC graphical output.
> +
> +Examples:
> +
> +       Run the host root fs inside a VM:
> +       $ ./Documentation/run-qemu.sh -r /
> +
> +       Run the same with SDL:
> +       $ ./Documentation/run-qemu.sh -r / --sdl
> +
> +       Or with a PPC build:
> +       $ ARCH=ppc ./Documentation/run-qemu.sh -r /
> +"
> +}
> +
> +function require_config() {
> +       if [ "$(grep CONFIG_$1=y .config)" ]; then
> +               return
> +       fi
> +
> +       echo "You need to enable CONFIG_$1 for run-qemu to work properly"
> +       exit 1
> +}
> +
> +function has_config() {
> +       grep "CONFIG_$1=y" .config
> +}
> +
> +function drive_if() {
> +       if [ "$(has_config VIRTIO_BLK)" ]; then
> +               echo virtio
> +       elif [ "$(has_config ATA_PIIX)" ]; then
> +               echo ide
> +       else
> +               echo "\
> +Your kernel must have either VIRTIO_BLK or ATA_PIIX
> +enabled for block device assignment" >&2
> +               exit 1
> +       fi
> +}
> +
> +GETOPT=`getopt -o a:d:hr:sS:v --long append,disk:,help,root:,sdl,smp:,vnc \
> +       -n "$(basename \"$0\")" -- "$@"`
> +
> +if [ $? != 0 ]; then
> +       echo "Terminating..." >&2
> +       exit 1
> +fi
> +
> +eval set -- "$GETOPT"
> +
> +while true; do
> +       case "$1" in
> +       -a|--append)
> +               KERNEL_APPEND2="$2"
> +               shift 2
> +               ;;
> +       -d|--disk)
> +               QEMU_OPTIONS="$QEMU_OPTIONS -drive \
> +                       file=$2,if=$(drive_if),cache=unsafe"
> +               USE_DISK=1
> +               shift 2
> +               ;;
> +       -h|--help)
> +               usage
> +               exit 0
> +               ;;
> +       -r|--root)
> +               ROOTFS="$2"
> +               shift 2
> +               ;;
> +       -s|--sdl)
> +               USE_SDL=1
> +               shift
> +               ;;
> +       -S|--smp)
> +               SMP="$2"
> +               shift 2
> +               ;;
> +       -v|--vnc)
> +               USE_VNC=1
> +               shift
> +               ;;
> +       --)
> +               shift
> +               break
> +               ;;
> +       *)
> +               echo "Could not parse option: $1" >&2
> +               exit 1
> +               ;;
> +       esac
> +done
> +
> +if [ ! "$ROOTFS" -a ! "$USE_DISK" ]; then
> +       echo "\
> +Error: Please specify at least -r or -d with a target \
> +FS to run off of" >&2
> +       exit 1
> +fi
> +
> +# Try to find the KVM accelerated Qemu binary
> +
> +[ "$ARCH" ] || ARCH=$(uname -m)
> +case $ARCH in
> +i*86|x86_64)
> +       KERNEL_BIN=arch/x86/boot/bzImage
> +       # SUSE and Red Hat call the binary qemu-kvm
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null)
> +
> +       # Debian and Gentoo call it kvm
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null)
> +
> +       # Qemu's own build system calls it qemu-system-x86_64
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-x86_64 2>/dev/null)

If you run qemu-system-x86_64 on an i386 host, will it use kvm at all?
If testing kvm  is not needed, then why don't you just grab the target
CPU from .config and use qemu-system-$CPU?

> +
> +       # i386 version of Qemu
> +       if [ ! "$(has_config X86_64)" ]; then
> +               [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu 2>/dev/null)

I'd just make a separate case for i386, even if the first two checks
are duplicated.

> +       fi
> +       ;;
> +s390*)
> +       KERNEL_BIN=arch/s390/boot/image
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-s390x 2>/dev/null)
> +       ;;
> +ppc*)
> +       KERNEL_BIN=vmlinux
> +
> +       IS_64BIT=
> +       [ "$(has_config PPC64)" ] && IS_64BIT=64
> +       if [ "$(has_config PPC_85xx)" ]; then
> +               QEMU_OPTIONS="$QEMU_OPTIONS -M mpc8544ds"
> +       elif [ "$(has_config PPC_PSERIES)" ]; then
> +               QEMU_OPTIONS="$QEMU_OPTIONS -M pseries"
> +               SERIAL=hvc0
> +               SERIAL_KCONFIG=HVC_CONSOLE
> +       elif [ "$(has_config PPC_PMAC)" ]; then
> +               [ "$(has_config SERIAL_PMACZILOG_TTYS)" ] || SERIAL=ttyPZ0
> +               SERIAL_KCONFIG=SERIAL_PMACZILOG
> +       else
> +               echo "Unknown PPC board" >&2
> +               exit 1
> +       fi
> +
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-ppc${IS_64BIT} 2>/dev/null)
> +       ;;
> +esac
> +
> +if [ ! "$QEMU_BIN" ]; then
> +       echo "\
> +Could not find a usable Qemu binary. Please install one from \
> +your distro or from source code." >&2
> +       exit 1
> +fi
> +
> +# The binaries without kvm in their name can be too old to support KVM, so
> +# check for that before the user gets confused
> +if [ ! "$(echo $QEMU_BIN | grep kvm)" -a \
> +     ! "$($QEMU_BIN --help | egrep '^-machine')" ]; then
> +       echo "Your Qemu binary is too old, please update to at least 0.15." >&2
> +       exit 1
> +fi
> +QEMU_OPTIONS="$QEMU_OPTIONS -machine accel=kvm:tcg"
> +
> +# We need to check some .config variables to make sure we actually work
> +# on the respective kernel.
> +if [ ! -e .config ]; then
> +       echo "\
> +Please run this script on a fully compiled and configured
> +Linux kernel build directory" >&2
> +       exit 1
> +fi
> +
> +if [ ! -e "$KERNEL_BIN" ]; then
> +       echo "Could not find kernel binary: $KERNEL_BIN" >&2
> +       exit 1
> +fi
> +
> +QEMU_OPTIONS="$QEMU_OPTIONS -kernel $KERNEL_BIN"
> +
> +if [ "$USE_SDL" ]; then
> +       # SDL is the default, so nothing to do
> +       :
> +elif [ "$USE_VNC" ]; then
> +       QEMU_OPTIONS="$QEMU_OPTIONS -vnc :5"
> +else
> +       # When emulating a serial console, tell the kernel to use it as well
> +       QEMU_OPTIONS="$QEMU_OPTIONS -nographic"
> +       KERNEL_APPEND="$KERNEL_APPEND console=$SERIAL earlyprintk=serial"
> +       MON_STDIO=1
> +       require_config "$SERIAL_KCONFIG"
> +fi
> +
> +if [ "$ROOTFS" ]; then
> +       # Using rootfs with 9p
> +       require_config "NET_9P_VIRTIO"
> +       KERNEL_APPEND="$KERNEL_APPEND \
> +root=/dev/root rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p"
> +
> +#Usage: -virtfs fstype,path=/share_path/,security_model=[mapped|passthrough|none],mount_tag=tag.
> +
> +
> +       QEMU_OPTIONS="$QEMU_OPTIONS \
> +-virtfs local,id=root,path=$ROOTFS,mount_tag=root,security_model=passthrough \
> +-device virtio-9p-pci,fsdev=root,mount_tag=/dev/root"
> +fi
> +
> +[ "$SMP" ] || SMP=1
> +
> +# User append args come last
> +KERNEL_APPEND="$KERNEL_APPEND $KERNEL_APPEND2"
> +
> +############### Execution #################
> +
> +echo "
> +       ################# Linux Qemu launcher #################
> +
> +This script executes your currently built Linux kernel using Qemu. If KVM is
> +available, it will also use KVM for fast virtualization of your guest.
> +
> +The intent is to make it very easy to run your kernel. If you need to do more
> +advanced things, such as passing through real devices, please take the command
> +line shown below and modify it to your needs. This tool is for simplicity, not
> +world dominating functionality coverage.

Please add this:
(just a hobby, won't be big and professional like libvirt)

Though usually Unix tools should be terse unless the user specifies -v.

> +"
> +echo "\
> +Your guest is bound to the current foreground shell. To quit the guest,
> +please use Ctrl-A x"
> +echo "  Executing: $QEMU_BIN $QEMU_OPTIONS -append \"$KERNEL_APPEND\" -smp $SMP"
> +echo
> +
> +exec $QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND -smp $SMP"

How about something like this (modulo quoting to allow compiling the
kernel in C:\Documents and Settings\agraf\):
CMD="$QEMU_BIN $QEMU_OPTIONS -append $KERNEL_APPEND -smp $SMP"
echo "  Executing: $CMD"
exec $CMD

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Avi Kivity]

On 08/24/2011 08:40 PM, Blue Swirl wrote:
> >  +
> >  +       # Qemu's own build system calls it qemu-system-x86_64
> >  +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-x86_64 2>/dev/null)
>
> If you run qemu-system-x86_64 on an i386 host, will it use kvm at all?

I think it will, and that's actually a bug, since kvm doesn't support 
virtualizing long mode on a 32-bit host.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Alexander Graf]

On 24.08.2011, at 00:31, Américo Wang wrote:

> On Wed, Aug 24, 2011 at 1:19 PM, Pekka Enberg <penberg@kernel.org> wrote:
>> 
>> It's nice to see such an honest attempt at improving QEMU usability, Alexander!
>> 
>> One comment: in my experience, having shell scripts under
>> Documentation reduces the likelihood that people actually discover
>> them so you might want to consider putting it under scripts or tools.
>> 
> 
> I was going to give the same suggestion, +1 for tools/ directory.

Well, scripts/ is a flat directory where I can just throw in the script. Tools however is split by tool and creating a full new directory for only a single script sounds a bit like overkill to me. I'll move it to scripts/ for now :)


Alex

Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Alexander Graf]

On 24.08.2011, at 04:16, Jan Kiszka wrote:

> On 2011-08-24 10:25, Avi Kivity wrote:
>> On 08/24/2011 01:16 AM, Alexander Graf wrote:
>>> +"
>>> +echo "\
>>> +Your guest is bound to the current foreground shell. To quit the guest,
>>> +please use Ctrl-A x"
>>> +echo "  Executing: $QEMU_BIN $QEMU_OPTIONS -append \"$KERNEL_APPEND\"
>>> -smp $SMP"
>>> +echo
>>> +
>>> +exec $QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND -smp $SMP"
>> 
>> Would be nice to support launching gdb in a separate terminal with
>> vmlinux already loaded, and already attached to qemu.
> 
> + loading a python script into gdb to pull in module symbols. There are
> a few implementations floating around (including my own one).

I'll leave that part to you then :). I haven't figured out a nice way how to get modules into the VM for now anyways.

> It would also be nice if one could append QEMU (note the capitalization
> BTW) options to the script, maybe everything after a '--' separator.

Good point :)


Alex

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Alexander Graf]

On 24.08.2011, at 12:40, Blue Swirl wrote:

> On Tue, Aug 23, 2011 at 10:16 PM, Alexander Graf <agraf@suse.de> wrote:
>> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
>> would be doing and what he expects from it. Basically he wants a
>> small and simple tool he and other developers can run to try out and
>> see if the kernel they just built actually works.
>> 
>> Fortunately, Qemu can do that today already! The only piece that was
>> missing was the "simple" piece of the equation, so here is a script
>> that wraps around Qemu and executes a kernel you just built.
>> 
>> If you do have KVM around and are not cross-compiling, it will use
>> KVM. But if you don't, you can still fall back to emulation mode and
>> at least check if your kernel still does what you expect. I only
>> implemented support for s390x and ppc there, but it's easily extensible
>> to more platforms, as Qemu can emulate (and virtualize) pretty much
>> any platform out there.
>> 
>> If you don't have qemu installed, please do so before using this script. Your
>> distro should provide a package for it (might even call it "kvm"). If not,
>> just compile it from source - it's not hard!
>> 
>> To quickly get going, just execute the following as user:
>> 
>>    $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>> 
>> This will drop you into a shell on your rootfs.
>> 
>> Happy hacking!
>> 
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>>  Documentation/run-qemu.sh |  284 +++++++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 284 insertions(+), 0 deletions(-)
>>  create mode 100755 Documentation/run-qemu.sh
>> 
>> diff --git a/Documentation/run-qemu.sh b/Documentation/run-qemu.sh
>> new file mode 100755
>> index 0000000..0bac924
>> --- /dev/null
>> +++ b/Documentation/run-qemu.sh
>> @@ -0,0 +1,284 @@
>> +#!/bin/bash
>> +#
>> +# QEMU Launcher
>> +#
>> +# This script enables simple use of the KVM and Qemu tool stack for
> 
> QEMU
> 
>> +# easy kernel testing. It allows to pass either a host directory to
>> +# the guest or a disk image. Example usage:
>> +#
>> +# Run the host root fs inside a VM:
>> +#
>> +# $ ./Documentation/run-qemu.sh -r /
>> +#
>> +# Run the same with SDL:
>> +#
>> +# $ ./Documentation/run-qemu.sh -r / --sdl
>> +#
>> +# Or with a PPC build:
>> +#
>> +# $ ARCH=ppc ./Documentation/run-qemu.sh -r /
>> +#
>> +#
>> +
>> +USE_SDL=
>> +USE_VNC=
>> +KERNEL_BIN=arch/x86/boot/bzImage
>> +MON_STDIO=
>> +KERNEL_APPEND2=
>> +SERIAL=ttyS0
>> +SERIAL_KCONFIG=SERIAL_8250
>> +
>> +function usage() {
>> +       echo "
>> +Run-Qemu allows you to execute a virtual machine with the Linux kernel
> 
> run-qemu.sh or $0
> 
>> +that you just built. To only execute a simple VM, you can just run it
>> +on your root fs with \"-r / -a init=/bin/bash\"
>> +
>> +       -a, --append parameters
>> +               Append the given parameters to the kernel command line
>> +
>> +       -d, --disk image
>> +               Add the image file as disk into the VM
>> +
>> +       -r, --root directory
>> +               Use the specified directory as root directory inside the guest.
>> +
>> +       -s, --sdl
>> +               Enable SDL graphical output.
>> +
>> +       -S, --smp cpus
>> +               Set number of virtual CPUs
>> +
>> +       -v, --vnc
>> +               Enable VNC graphical output.
>> +
>> +Examples:
>> +
>> +       Run the host root fs inside a VM:
>> +       $ ./Documentation/run-qemu.sh -r /
>> +
>> +       Run the same with SDL:
>> +       $ ./Documentation/run-qemu.sh -r / --sdl
>> +
>> +       Or with a PPC build:
>> +       $ ARCH=ppc ./Documentation/run-qemu.sh -r /
>> +"
>> +}
>> +
>> +function require_config() {
>> +       if [ "$(grep CONFIG_$1=y .config)" ]; then
>> +               return
>> +       fi
>> +
>> +       echo "You need to enable CONFIG_$1 for run-qemu to work properly"
>> +       exit 1
>> +}
>> +
>> +function has_config() {
>> +       grep "CONFIG_$1=y" .config
>> +}
>> +
>> +function drive_if() {
>> +       if [ "$(has_config VIRTIO_BLK)" ]; then
>> +               echo virtio
>> +       elif [ "$(has_config ATA_PIIX)" ]; then
>> +               echo ide
>> +       else
>> +               echo "\
>> +Your kernel must have either VIRTIO_BLK or ATA_PIIX
>> +enabled for block device assignment" >&2
>> +               exit 1
>> +       fi
>> +}
>> +
>> +GETOPT=`getopt -o a:d:hr:sS:v --long append,disk:,help,root:,sdl,smp:,vnc \
>> +       -n "$(basename \"$0\")" -- "$@"`
>> +
>> +if [ $? != 0 ]; then
>> +       echo "Terminating..." >&2
>> +       exit 1
>> +fi
>> +
>> +eval set -- "$GETOPT"
>> +
>> +while true; do
>> +       case "$1" in
>> +       -a|--append)
>> +               KERNEL_APPEND2="$2"
>> +               shift 2
>> +               ;;
>> +       -d|--disk)
>> +               QEMU_OPTIONS="$QEMU_OPTIONS -drive \
>> +                       file=$2,if=$(drive_if),cache=unsafe"
>> +               USE_DISK=1
>> +               shift 2
>> +               ;;
>> +       -h|--help)
>> +               usage
>> +               exit 0
>> +               ;;
>> +       -r|--root)
>> +               ROOTFS="$2"
>> +               shift 2
>> +               ;;
>> +       -s|--sdl)
>> +               USE_SDL=1
>> +               shift
>> +               ;;
>> +       -S|--smp)
>> +               SMP="$2"
>> +               shift 2
>> +               ;;
>> +       -v|--vnc)
>> +               USE_VNC=1
>> +               shift
>> +               ;;
>> +       --)
>> +               shift
>> +               break
>> +               ;;
>> +       *)
>> +               echo "Could not parse option: $1" >&2
>> +               exit 1
>> +               ;;
>> +       esac
>> +done
>> +
>> +if [ ! "$ROOTFS" -a ! "$USE_DISK" ]; then
>> +       echo "\
>> +Error: Please specify at least -r or -d with a target \
>> +FS to run off of" >&2
>> +       exit 1
>> +fi
>> +
>> +# Try to find the KVM accelerated Qemu binary
>> +
>> +[ "$ARCH" ] || ARCH=$(uname -m)
>> +case $ARCH in
>> +i*86|x86_64)
>> +       KERNEL_BIN=arch/x86/boot/bzImage
>> +       # SUSE and Red Hat call the binary qemu-kvm
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null)
>> +
>> +       # Debian and Gentoo call it kvm
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null)
>> +
>> +       # Qemu's own build system calls it qemu-system-x86_64
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-x86_64 2>/dev/null)
> 
> If you run qemu-system-x86_64 on an i386 host, will it use kvm at all?
> If testing kvm  is not needed, then why don't you just grab the target
> CPU from .config and use qemu-system-$CPU?

Well, how do you find out if it's needed? The goal is to use as few command line parameters as possible to get a kernel test going. And most people will want to use KVM if it's available, right? Plus, on x86_64, there are very few machines that don't support KVM these days.

Also, how would you fetch $CPU from .config? I haven't found anything in .config that is explicitly telling me the ARCH for the respective build.

> 
>> +
>> +       # i386 version of Qemu
>> +       if [ ! "$(has_config X86_64)" ]; then
>> +               [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu 2>/dev/null)
> 
> I'd just make a separate case for i386, even if the first two checks
> are duplicated.

Hrm. On i386 we can just always fall back to the qemu binary I'd say. You're pretty unlikely to get KVM there and if you do, -machine accel= should sort that one out for you.

> 
>> +       fi
>> +       ;;
>> +s390*)
>> +       KERNEL_BIN=arch/s390/boot/image
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-s390x 2>/dev/null)
>> +       ;;
>> +ppc*)
>> +       KERNEL_BIN=vmlinux
>> +
>> +       IS_64BIT=
>> +       [ "$(has_config PPC64)" ] && IS_64BIT=64
>> +       if [ "$(has_config PPC_85xx)" ]; then
>> +               QEMU_OPTIONS="$QEMU_OPTIONS -M mpc8544ds"
>> +       elif [ "$(has_config PPC_PSERIES)" ]; then
>> +               QEMU_OPTIONS="$QEMU_OPTIONS -M pseries"
>> +               SERIAL=hvc0
>> +               SERIAL_KCONFIG=HVC_CONSOLE
>> +       elif [ "$(has_config PPC_PMAC)" ]; then
>> +               [ "$(has_config SERIAL_PMACZILOG_TTYS)" ] || SERIAL=ttyPZ0
>> +               SERIAL_KCONFIG=SERIAL_PMACZILOG
>> +       else
>> +               echo "Unknown PPC board" >&2
>> +               exit 1
>> +       fi
>> +
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-ppc${IS_64BIT} 2>/dev/null)
>> +       ;;
>> +esac
>> +
>> +if [ ! "$QEMU_BIN" ]; then
>> +       echo "\
>> +Could not find a usable Qemu binary. Please install one from \
>> +your distro or from source code." >&2
>> +       exit 1
>> +fi
>> +
>> +# The binaries without kvm in their name can be too old to support KVM, so
>> +# check for that before the user gets confused
>> +if [ ! "$(echo $QEMU_BIN | grep kvm)" -a \
>> +     ! "$($QEMU_BIN --help | egrep '^-machine')" ]; then
>> +       echo "Your Qemu binary is too old, please update to at least 0.15." >&2
>> +       exit 1
>> +fi
>> +QEMU_OPTIONS="$QEMU_OPTIONS -machine accel=kvm:tcg"
>> +
>> +# We need to check some .config variables to make sure we actually work
>> +# on the respective kernel.
>> +if [ ! -e .config ]; then
>> +       echo "\
>> +Please run this script on a fully compiled and configured
>> +Linux kernel build directory" >&2
>> +       exit 1
>> +fi
>> +
>> +if [ ! -e "$KERNEL_BIN" ]; then
>> +       echo "Could not find kernel binary: $KERNEL_BIN" >&2
>> +       exit 1
>> +fi
>> +
>> +QEMU_OPTIONS="$QEMU_OPTIONS -kernel $KERNEL_BIN"
>> +
>> +if [ "$USE_SDL" ]; then
>> +       # SDL is the default, so nothing to do
>> +       :
>> +elif [ "$USE_VNC" ]; then
>> +       QEMU_OPTIONS="$QEMU_OPTIONS -vnc :5"
>> +else
>> +       # When emulating a serial console, tell the kernel to use it as well
>> +       QEMU_OPTIONS="$QEMU_OPTIONS -nographic"
>> +       KERNEL_APPEND="$KERNEL_APPEND console=$SERIAL earlyprintk=serial"
>> +       MON_STDIO=1
>> +       require_config "$SERIAL_KCONFIG"
>> +fi
>> +
>> +if [ "$ROOTFS" ]; then
>> +       # Using rootfs with 9p
>> +       require_config "NET_9P_VIRTIO"
>> +       KERNEL_APPEND="$KERNEL_APPEND \
>> +root=/dev/root rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p"
>> +
>> +#Usage: -virtfs fstype,path=/share_path/,security_model=[mapped|passthrough|none],mount_tag=tag.
>> +
>> +
>> +       QEMU_OPTIONS="$QEMU_OPTIONS \
>> +-virtfs local,id=root,path=$ROOTFS,mount_tag=root,security_model=passthrough \
>> +-device virtio-9p-pci,fsdev=root,mount_tag=/dev/root"
>> +fi
>> +
>> +[ "$SMP" ] || SMP=1
>> +
>> +# User append args come last
>> +KERNEL_APPEND="$KERNEL_APPEND $KERNEL_APPEND2"
>> +
>> +############### Execution #################
>> +
>> +echo "
>> +       ################# Linux Qemu launcher #################
>> +
>> +This script executes your currently built Linux kernel using Qemu. If KVM is
>> +available, it will also use KVM for fast virtualization of your guest.
>> +
>> +The intent is to make it very easy to run your kernel. If you need to do more
>> +advanced things, such as passing through real devices, please take the command
>> +line shown below and modify it to your needs. This tool is for simplicity, not
>> +world dominating functionality coverage.
> 
> Please add this:
> (just a hobby, won't be big and professional like libvirt)
> 
> Though usually Unix tools should be terse unless the user specifies -v.
> 
>> +"
>> +echo "\
>> +Your guest is bound to the current foreground shell. To quit the guest,
>> +please use Ctrl-A x"
>> +echo "  Executing: $QEMU_BIN $QEMU_OPTIONS -append \"$KERNEL_APPEND\" -smp $SMP"
>> +echo
>> +
>> +exec $QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND -smp $SMP"
> 
> How about something like this (modulo quoting to allow compiling the
> kernel in C:\Documents and Settings\agraf\):
> CMD="$QEMU_BIN $QEMU_OPTIONS -append $KERNEL_APPEND -smp $SMP"
> echo "  Executing: $CMD"
> exec $CMD

Yeah, I tried that, but my bash foo is not good enough :(. The quoting isn't quite as simple. I think I'd have to make this be an array - and before I do that I'd rather have the code be slightly more verbose.


Alex

Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Américo Wang]

On Thu, Aug 25, 2011 at 4:35 AM, Alexander Graf <agraf@suse.de> wrote:
>
> On 24.08.2011, at 00:31, Américo Wang wrote:
>
>> On Wed, Aug 24, 2011 at 1:19 PM, Pekka Enberg <penberg@kernel.org> wrote:
>>>
>>> It's nice to see such an honest attempt at improving QEMU usability, Alexander!
>>>
>>> One comment: in my experience, having shell scripts under
>>> Documentation reduces the likelihood that people actually discover
>>> them so you might want to consider putting it under scripts or tools.
>>>
>>
>> I was going to give the same suggestion, +1 for tools/ directory.
>
> Well, scripts/ is a flat directory where I can just throw in the script. Tools however is split by tool and creating a full new directory for only a single script sounds a bit like overkill to me. I'll move it to scripts/ for now :)

How about the directory tools/testing/ ?

scripts/ is mainly for the tools/utilities we use to build kernel or
do kernel dev,
it is not so suitable for your script IMHO.

Thanks.

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Blue Swirl]

On Wed, Aug 24, 2011 at 9:38 PM, Alexander Graf <agraf@suse.de> wrote:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just built actually works.
>
> Fortunately, QEMU can do that today already! The only piece that was
> missing was the "simple" piece of the equation, so here is a script
> that wraps around QEMU and executes a kernel you just built.
>
> If you do have KVM around and are not cross-compiling, it will use
> KVM. But if you don't, you can still fall back to emulation mode and
> at least check if your kernel still does what you expect. I only
> implemented support for s390x and ppc there, but it's easily extensible
> to more platforms, as QEMU can emulate (and virtualize) pretty much
> any platform out there.
>
> If you don't have qemu installed, please do so before using this script. Your
> distro should provide a package for it (might even call it "kvm"). If not,
> just compile it from source - it's not hard!
>
> To quickly get going, just execute the following as user:
>
>    $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>
> This will drop you into a shell on your rootfs.
>
> Happy hacking!
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v1 -> v2:
>
>  - fix naming of QEMU
>  - use grep -q for has_config
>  - support multiple -a args
>  - spawn gdb on execution
>  - pass through qemu options
>  - dont use qemu-system-x86_64 on i386
>  - add funny sentence to startup text
>  - more helpful error messages
> ---
>  scripts/run-qemu.sh |  334 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 334 insertions(+), 0 deletions(-)
>  create mode 100755 scripts/run-qemu.sh
>
> diff --git a/scripts/run-qemu.sh b/scripts/run-qemu.sh
> new file mode 100755
> index 0000000..5d4e185
> --- /dev/null
> +++ b/scripts/run-qemu.sh
> @@ -0,0 +1,334 @@
> +#!/bin/bash
> +#
> +# QEMU Launcher
> +#
> +# This script enables simple use of the KVM and QEMU tool stack for
> +# easy kernel testing. It allows to pass either a host directory to
> +# the guest or a disk image. Example usage:
> +#
> +# Run the host root fs inside a VM:
> +#
> +# $ ./scripts/run-qemu.sh -r /
> +#
> +# Run the same with SDL:
> +#
> +# $ ./scripts/run-qemu.sh -r / --sdl
> +#
> +# Or with a PPC build:
> +#
> +# $ ARCH=ppc ./scripts/run-qemu.sh -r /
> +#
> +# PPC with a mac99 model by passing options to QEMU:
> +#
> +# $ ARCH=ppc ./scripts/run-qemu.sh -r / -- -M mac99
> +#
> +
> +USE_SDL=
> +USE_VNC=
> +USE_GDB=1
> +KERNEL_BIN=arch/x86/boot/bzImage
> +MON_STDIO=
> +KERNEL_APPEND2=
> +SERIAL=ttyS0
> +SERIAL_KCONFIG=SERIAL_8250
> +BASENAME=$(basename "$0")
> +
> +function usage() {
> +       echo "
> +$BASENAME allows you to execute a virtual machine with the Linux kernel
> +that you just built. To only execute a simple VM, you can just run it
> +on your root fs with \"-r / -a init=/bin/bash\"
> +
> +       -a, --append parameters
> +               Append the given parameters to the kernel command line.
> +
> +       -d, --disk image
> +               Add the image file as disk into the VM.
> +
> +       -D, --no-gdb
> +               Don't run an xterm with gdb attached to the guest.
> +
> +       -r, --root directory
> +               Use the specified directory as root directory inside the guest.
> +
> +       -s, --sdl
> +               Enable SDL graphical output.
> +
> +       -S, --smp cpus
> +               Set number of virtual CPUs.
> +
> +       -v, --vnc
> +               Enable VNC graphical output.
> +
> +Examples:
> +
> +       Run the host root fs inside a VM:
> +       $ ./scripts/run-qemu.sh -r /
> +
> +       Run the same with SDL:
> +       $ ./scripts/run-qemu.sh -r / --sdl
> +
> +       Or with a PPC build:
> +       $ ARCH=ppc ./scripts/run-qemu.sh -r /
> +
> +       PPC with a mac99 model by passing options to QEMU:
> +       $ ARCH=ppc ./scripts/run-qemu.sh -r / -- -M mac99
> +"
> +}
> +
> +function require_config() {
> +       if [ "$(grep CONFIG_$1=y .config)" ]; then
> +               return
> +       fi
> +
> +       echo "You need to enable CONFIG_$1 for run-qemu to work properly"
> +       exit 1
> +}
> +
> +function has_config() {
> +       grep -q "CONFIG_$1=y" .config
> +}
> +
> +function drive_if() {
> +       if has_config VIRTIO_BLK; then
> +               echo virtio
> +       elif has_config ATA_PIIX; then
> +               echo ide
> +       else
> +               echo "\
> +Your kernel must have either VIRTIO_BLK or ATA_PIIX
> +enabled for block device assignment" >&2
> +               exit 1
> +       fi
> +}
> +
> +GETOPT=`getopt -o a:d:Dhr:sS:v --long append,disk:,no-gdb,help,root:,sdl,smp:,vnc \
> +       -n "$(basename \"$0\")" -- "$@"`
> +
> +if [ $? != 0 ]; then
> +       echo "Terminating..." >&2
> +       exit 1
> +fi
> +
> +eval set -- "$GETOPT"
> +
> +while true; do
> +       case "$1" in
> +       -a|--append)
> +               KERNEL_APPEND2="$KERNEL_APPEND2 $KERNEL_APPEND2"
> +               shift
> +               ;;
> +       -d|--disk)
> +               QEMU_OPTIONS="$QEMU_OPTIONS -drive \
> +                       file=$2,if=$(drive_if),cache=unsafe"
> +               USE_DISK=1
> +               shift
> +               ;;
> +       -D|--no-gdb)
> +               USE_GDB=
> +               ;;
> +       -h|--help)
> +               usage
> +               exit 0
> +               ;;
> +       -r|--root)
> +               ROOTFS="$2"
> +               shift
> +               ;;
> +       -s|--sdl)
> +               USE_SDL=1
> +               ;;
> +       -S|--smp)
> +               SMP="$2"
> +               shift
> +               ;;
> +       -v|--vnc)
> +               USE_VNC=1
> +               ;;
> +       --)
> +               shift
> +               break
> +               ;;
> +       *)
> +               echo "Could not parse option: $1" >&2
> +               exit 1
> +               ;;
> +       esac
> +       shift
> +done
> +
> +if [ ! "$ROOTFS" -a ! "$USE_DISK" ]; then
> +       echo "\
> +Error: Please specify at least -r or -d with a target \
> +FS to run off of" >&2
> +       exit 1
> +fi
> +
> +# Try to find the KVM accelerated QEMU binary
> +
> +[ "$ARCH" ] || ARCH=$(uname -m)
> +case $ARCH in
> +x86_64)
> +       KERNEL_BIN=arch/x86/boot/bzImage
> +       # SUSE and Red Hat call the binary qemu-kvm
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null)
> +
> +       # Debian and Gentoo call it kvm
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null)
> +
> +       # QEMU's own build system calls it qemu-system-x86_64
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-x86_64 2>/dev/null)
> +       ;;
> +i*86)
> +       KERNEL_BIN=arch/x86/boot/bzImage
> +       # SUSE and Red Hat call the binary qemu-kvm
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null)
> +
> +       # Debian and Gentoo call it kvm
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null)
> +
> +       KERNEL_BIN=arch/x86/boot/bzImage
> +       # i386 version of QEMU
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu 2>/dev/null)
> +       ;;
> +s390*)
> +       KERNEL_BIN=arch/s390/boot/image
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-s390x 2>/dev/null)
> +       ;;
> +ppc*)
> +       KERNEL_BIN=vmlinux
> +
> +       IS_64BIT=
> +       has_config PPC64 && IS_64BIT=64
> +       if has_config PPC_85xx; then
> +               QEMU_OPTIONS="$QEMU_OPTIONS -M mpc8544ds"
> +       elif has_config PPC_PSERIES; then
> +               QEMU_OPTIONS="$QEMU_OPTIONS -M pseries"
> +               SERIAL=hvc0
> +               SERIAL_KCONFIG=HVC_CONSOLE
> +       elif has_config PPC_PMAC; then
> +               has_config SERIAL_PMACZILOG_TTYS || SERIAL=ttyPZ0
> +               SERIAL_KCONFIG=SERIAL_PMACZILOG
> +       else
> +               echo "Unknown PPC board" >&2
> +               exit 1
> +       fi
> +
> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-ppc${IS_64BIT} 2>/dev/null)
> +       ;;
> +esac
> +
> +if [ ! -e "$QEMU_BIN" ]; then
> +       echo "\
> +Could not find a usable QEMU binary. Please install one from \
> +your distro or from source code using:
> +
> +  $ git clone git://git.qemu.org/qemu.git
> +  $ cd qemu
> +  $ ./configure
> +  $ make -j
> +  $ sudo make install
> +" >&2
> +       exit 1
> +fi
> +
> +# The binaries without kvm in their name can be too old to support KVM, so
> +# check for that before the user gets confused
> +if [ ! "$(echo $QEMU_BIN | grep kvm)" -a \
> +     ! "$($QEMU_BIN --help | egrep '^-machine')" ]; then
> +       echo "Your QEMU binary is too old, please update to at least 0.15." >&2
> +       exit 1
> +fi
> +QEMU_OPTIONS="$QEMU_OPTIONS -machine accel=kvm:tcg"
> +
> +# We need to check some .config variables to make sure we actually work
> +# on the respective kernel.
> +if [ ! -e .config ]; then
> +       echo "\
> +Please run this script on a fully compiled and configured
> +Linux kernel build directory" >&2
> +       exit 1
> +fi
> +
> +if [ ! -e "$KERNEL_BIN" ]; then
> +       echo "Could not find kernel binary: $KERNEL_BIN" >&2
> +       exit 1
> +fi
> +
> +QEMU_OPTIONS="$QEMU_OPTIONS -kernel $KERNEL_BIN"
> +
> +if [ "$USE_SDL" ]; then
> +       # SDL is the default, so nothing to do
> +       :
> +elif [ "$USE_VNC" ]; then
> +       QEMU_OPTIONS="$QEMU_OPTIONS -vnc :5"
> +else
> +       # When emulating a serial console, tell the kernel to use it as well
> +       QEMU_OPTIONS="$QEMU_OPTIONS -nographic"
> +       KERNEL_APPEND="$KERNEL_APPEND console=$SERIAL earlyprintk=serial"
> +       MON_STDIO=1
> +       require_config "$SERIAL_KCONFIG"
> +fi
> +
> +if [ "$ROOTFS" ]; then
> +       # Using rootfs with 9p
> +       require_config "NET_9P_VIRTIO"
> +       KERNEL_APPEND="$KERNEL_APPEND \
> +root=/dev/root rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p"
> +
> +#Usage: -virtfs fstype,path=/share_path/,security_model=[mapped|passthrough|none],mount_tag=tag.
> +
> +
> +       QEMU_OPTIONS="$QEMU_OPTIONS \
> +-virtfs local,id=root,path=$ROOTFS,mount_tag=root,security_model=passthrough \
> +-device virtio-9p-pci,fsdev=root,mount_tag=/dev/root"
> +fi
> +
> +[ "$SMP" ] || SMP=1
> +
> +# User append args come last
> +KERNEL_APPEND="$KERNEL_APPEND $KERNEL_APPEND2"
> +
> +############### Execution #################
> +
> +QEMU_OPTIONS="$QEMU_OPTIONS -smp $SMP"
> +
> +echo "
> +       ################# Linux QEMU launcher #################
> +
> +This script executes your currently built Linux kernel using QEMU. If KVM is
> +available, it will also use KVM for fast virtualization of your guest.
> +
> +The intent is to make it very easy to run your kernel. If you need to do more
> +advanced things, such as passing through real devices, please use QEMU command
> +line options and add them to the $BASENAME command line using --.
> +
> +This tool is for simplicity, not world dominating functionality coverage.
> +(just a hobby, won't be big and professional like libvirt)
> +
> +"
> +
> +if [ "$MON_STDIO" ]; then
> +       echo "\
> +### Your guest is bound to the current foreground shell. To quit the guest, ###
> +### please use Ctrl-A x                                                     ###
> +"
> +fi
> +
> +echo "  Executing: $QEMU_BIN $QEMU_OPTIONS -append \"$KERNEL_APPEND\""

This line does not match [1] below.

> +echo
> +
> +GDB_PID=
> +if [ "$USE_GDB" -a "$DISPLAY" -a -x "$(which xterm)" -a -e "$(which gdb)" ]; then
> +       # Run a gdb console in parallel to the kernel
> +
> +       # XXX find out if port is in use
> +       PORT=$$

$$ could be <1024.

> +       xterm -T "$BASENAME" -e "sleep 2; gdb vmlinux -ex 'target remote localhost:$PORT' -ex c" &

But the gnomes might not have xterms but instead gterms and so on.
Then there are wrappers like x-terminal-emulator on some distros.

> +       GDB_PID=$!
> +       QEMU_OPTIONS="$QEMU_OPTIONS -gdb tcp::$PORT"
> +fi
> +
> +$QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND" "$@"

[1]

> +wait $GDB_PID &>/dev/null
> +
> --
> 1.6.0.2
>
>
>

Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Alexander Graf]

On 24.08.2011, at 20:44, Américo Wang wrote:

> On Thu, Aug 25, 2011 at 4:35 AM, Alexander Graf <agraf@suse.de> wrote:
>> 
>> On 24.08.2011, at 00:31, Américo Wang wrote:
>> 
>>> On Wed, Aug 24, 2011 at 1:19 PM, Pekka Enberg <penberg@kernel.org> wrote:
>>>> 
>>>> It's nice to see such an honest attempt at improving QEMU usability, Alexander!
>>>> 
>>>> One comment: in my experience, having shell scripts under
>>>> Documentation reduces the likelihood that people actually discover
>>>> them so you might want to consider putting it under scripts or tools.
>>>> 
>>> 
>>> I was going to give the same suggestion, +1 for tools/ directory.
>> 
>> Well, scripts/ is a flat directory where I can just throw in the script. Tools however is split by tool and creating a full new directory for only a single script sounds a bit like overkill to me. I'll move it to scripts/ for now :)
> 
> How about the directory tools/testing/ ?
> 
> scripts/ is mainly for the tools/utilities we use to build kernel or
> do kernel dev,
> it is not so suitable for your script IMHO.

Good idea! I talked to Steven about it as well and completely forgot your email pointing me to the same directory. I guess that one does fit it pretty well.


Alex

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Alexander Graf]

On 25.08.2011, at 11:01, Blue Swirl wrote:

> On Wed, Aug 24, 2011 at 9:38 PM, Alexander Graf <agraf@suse.de> wrote:
>> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
>> would be doing and what he expects from it. Basically he wants a
>> small and simple tool he and other developers can run to try out and
>> see if the kernel they just built actually works.
>> 
>> Fortunately, QEMU can do that today already! The only piece that was
>> missing was the "simple" piece of the equation, so here is a script
>> that wraps around QEMU and executes a kernel you just built.
>> 
>> If you do have KVM around and are not cross-compiling, it will use
>> KVM. But if you don't, you can still fall back to emulation mode and
>> at least check if your kernel still does what you expect. I only
>> implemented support for s390x and ppc there, but it's easily extensible
>> to more platforms, as QEMU can emulate (and virtualize) pretty much
>> any platform out there.
>> 
>> If you don't have qemu installed, please do so before using this script. Your
>> distro should provide a package for it (might even call it "kvm"). If not,
>> just compile it from source - it's not hard!
>> 
>> To quickly get going, just execute the following as user:
>> 
>>    $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>> 
>> This will drop you into a shell on your rootfs.
>> 
>> Happy hacking!
>> 
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> 
>> ---
>> 
>> v1 -> v2:
>> 
>>  - fix naming of QEMU
>>  - use grep -q for has_config
>>  - support multiple -a args
>>  - spawn gdb on execution
>>  - pass through qemu options
>>  - dont use qemu-system-x86_64 on i386
>>  - add funny sentence to startup text
>>  - more helpful error messages
>> ---
>>  scripts/run-qemu.sh |  334 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 334 insertions(+), 0 deletions(-)
>>  create mode 100755 scripts/run-qemu.sh
>> 
>> diff --git a/scripts/run-qemu.sh b/scripts/run-qemu.sh
>> new file mode 100755
>> index 0000000..5d4e185
>> --- /dev/null
>> +++ b/scripts/run-qemu.sh
>> @@ -0,0 +1,334 @@
>> +#!/bin/bash
>> +#
>> +# QEMU Launcher
>> +#
>> +# This script enables simple use of the KVM and QEMU tool stack for
>> +# easy kernel testing. It allows to pass either a host directory to
>> +# the guest or a disk image. Example usage:
>> +#
>> +# Run the host root fs inside a VM:
>> +#
>> +# $ ./scripts/run-qemu.sh -r /
>> +#
>> +# Run the same with SDL:
>> +#
>> +# $ ./scripts/run-qemu.sh -r / --sdl
>> +#
>> +# Or with a PPC build:
>> +#
>> +# $ ARCH=ppc ./scripts/run-qemu.sh -r /
>> +#
>> +# PPC with a mac99 model by passing options to QEMU:
>> +#
>> +# $ ARCH=ppc ./scripts/run-qemu.sh -r / -- -M mac99
>> +#
>> +
>> +USE_SDL=
>> +USE_VNC=
>> +USE_GDB=1
>> +KERNEL_BIN=arch/x86/boot/bzImage
>> +MON_STDIO=
>> +KERNEL_APPEND2=
>> +SERIAL=ttyS0
>> +SERIAL_KCONFIG=SERIAL_8250
>> +BASENAME=$(basename "$0")
>> +
>> +function usage() {
>> +       echo "
>> +$BASENAME allows you to execute a virtual machine with the Linux kernel
>> +that you just built. To only execute a simple VM, you can just run it
>> +on your root fs with \"-r / -a init=/bin/bash\"
>> +
>> +       -a, --append parameters
>> +               Append the given parameters to the kernel command line.
>> +
>> +       -d, --disk image
>> +               Add the image file as disk into the VM.
>> +
>> +       -D, --no-gdb
>> +               Don't run an xterm with gdb attached to the guest.
>> +
>> +       -r, --root directory
>> +               Use the specified directory as root directory inside the guest.
>> +
>> +       -s, --sdl
>> +               Enable SDL graphical output.
>> +
>> +       -S, --smp cpus
>> +               Set number of virtual CPUs.
>> +
>> +       -v, --vnc
>> +               Enable VNC graphical output.
>> +
>> +Examples:
>> +
>> +       Run the host root fs inside a VM:
>> +       $ ./scripts/run-qemu.sh -r /
>> +
>> +       Run the same with SDL:
>> +       $ ./scripts/run-qemu.sh -r / --sdl
>> +
>> +       Or with a PPC build:
>> +       $ ARCH=ppc ./scripts/run-qemu.sh -r /
>> +
>> +       PPC with a mac99 model by passing options to QEMU:
>> +       $ ARCH=ppc ./scripts/run-qemu.sh -r / -- -M mac99
>> +"
>> +}
>> +
>> +function require_config() {
>> +       if [ "$(grep CONFIG_$1=y .config)" ]; then
>> +               return
>> +       fi
>> +
>> +       echo "You need to enable CONFIG_$1 for run-qemu to work properly"
>> +       exit 1
>> +}
>> +
>> +function has_config() {
>> +       grep -q "CONFIG_$1=y" .config
>> +}
>> +
>> +function drive_if() {
>> +       if has_config VIRTIO_BLK; then
>> +               echo virtio
>> +       elif has_config ATA_PIIX; then
>> +               echo ide
>> +       else
>> +               echo "\
>> +Your kernel must have either VIRTIO_BLK or ATA_PIIX
>> +enabled for block device assignment" >&2
>> +               exit 1
>> +       fi
>> +}
>> +
>> +GETOPT=`getopt -o a:d:Dhr:sS:v --long append,disk:,no-gdb,help,root:,sdl,smp:,vnc \
>> +       -n "$(basename \"$0\")" -- "$@"`
>> +
>> +if [ $? != 0 ]; then
>> +       echo "Terminating..." >&2
>> +       exit 1
>> +fi
>> +
>> +eval set -- "$GETOPT"
>> +
>> +while true; do
>> +       case "$1" in
>> +       -a|--append)
>> +               KERNEL_APPEND2="$KERNEL_APPEND2 $KERNEL_APPEND2"
>> +               shift
>> +               ;;
>> +       -d|--disk)
>> +               QEMU_OPTIONS="$QEMU_OPTIONS -drive \
>> +                       file=$2,if=$(drive_if),cache=unsafe"
>> +               USE_DISK=1
>> +               shift
>> +               ;;
>> +       -D|--no-gdb)
>> +               USE_GDB=
>> +               ;;
>> +       -h|--help)
>> +               usage
>> +               exit 0
>> +               ;;
>> +       -r|--root)
>> +               ROOTFS="$2"
>> +               shift
>> +               ;;
>> +       -s|--sdl)
>> +               USE_SDL=1
>> +               ;;
>> +       -S|--smp)
>> +               SMP="$2"
>> +               shift
>> +               ;;
>> +       -v|--vnc)
>> +               USE_VNC=1
>> +               ;;
>> +       --)
>> +               shift
>> +               break
>> +               ;;
>> +       *)
>> +               echo "Could not parse option: $1" >&2
>> +               exit 1
>> +               ;;
>> +       esac
>> +       shift
>> +done
>> +
>> +if [ ! "$ROOTFS" -a ! "$USE_DISK" ]; then
>> +       echo "\
>> +Error: Please specify at least -r or -d with a target \
>> +FS to run off of" >&2
>> +       exit 1
>> +fi
>> +
>> +# Try to find the KVM accelerated QEMU binary
>> +
>> +[ "$ARCH" ] || ARCH=$(uname -m)
>> +case $ARCH in
>> +x86_64)
>> +       KERNEL_BIN=arch/x86/boot/bzImage
>> +       # SUSE and Red Hat call the binary qemu-kvm
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null)
>> +
>> +       # Debian and Gentoo call it kvm
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null)
>> +
>> +       # QEMU's own build system calls it qemu-system-x86_64
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-x86_64 2>/dev/null)
>> +       ;;
>> +i*86)
>> +       KERNEL_BIN=arch/x86/boot/bzImage
>> +       # SUSE and Red Hat call the binary qemu-kvm
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null)
>> +
>> +       # Debian and Gentoo call it kvm
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null)
>> +
>> +       KERNEL_BIN=arch/x86/boot/bzImage
>> +       # i386 version of QEMU
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu 2>/dev/null)
>> +       ;;
>> +s390*)
>> +       KERNEL_BIN=arch/s390/boot/image
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-s390x 2>/dev/null)
>> +       ;;
>> +ppc*)
>> +       KERNEL_BIN=vmlinux
>> +
>> +       IS_64BIT=
>> +       has_config PPC64 && IS_64BIT=64
>> +       if has_config PPC_85xx; then
>> +               QEMU_OPTIONS="$QEMU_OPTIONS -M mpc8544ds"
>> +       elif has_config PPC_PSERIES; then
>> +               QEMU_OPTIONS="$QEMU_OPTIONS -M pseries"
>> +               SERIAL=hvc0
>> +               SERIAL_KCONFIG=HVC_CONSOLE
>> +       elif has_config PPC_PMAC; then
>> +               has_config SERIAL_PMACZILOG_TTYS || SERIAL=ttyPZ0
>> +               SERIAL_KCONFIG=SERIAL_PMACZILOG
>> +       else
>> +               echo "Unknown PPC board" >&2
>> +               exit 1
>> +       fi
>> +
>> +       [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-ppc${IS_64BIT} 2>/dev/null)
>> +       ;;
>> +esac
>> +
>> +if [ ! -e "$QEMU_BIN" ]; then
>> +       echo "\
>> +Could not find a usable QEMU binary. Please install one from \
>> +your distro or from source code using:
>> +
>> +  $ git clone git://git.qemu.org/qemu.git
>> +  $ cd qemu
>> +  $ ./configure
>> +  $ make -j
>> +  $ sudo make install
>> +" >&2
>> +       exit 1
>> +fi
>> +
>> +# The binaries without kvm in their name can be too old to support KVM, so
>> +# check for that before the user gets confused
>> +if [ ! "$(echo $QEMU_BIN | grep kvm)" -a \
>> +     ! "$($QEMU_BIN --help | egrep '^-machine')" ]; then
>> +       echo "Your QEMU binary is too old, please update to at least 0.15." >&2
>> +       exit 1
>> +fi
>> +QEMU_OPTIONS="$QEMU_OPTIONS -machine accel=kvm:tcg"
>> +
>> +# We need to check some .config variables to make sure we actually work
>> +# on the respective kernel.
>> +if [ ! -e .config ]; then
>> +       echo "\
>> +Please run this script on a fully compiled and configured
>> +Linux kernel build directory" >&2
>> +       exit 1
>> +fi
>> +
>> +if [ ! -e "$KERNEL_BIN" ]; then
>> +       echo "Could not find kernel binary: $KERNEL_BIN" >&2
>> +       exit 1
>> +fi
>> +
>> +QEMU_OPTIONS="$QEMU_OPTIONS -kernel $KERNEL_BIN"
>> +
>> +if [ "$USE_SDL" ]; then
>> +       # SDL is the default, so nothing to do
>> +       :
>> +elif [ "$USE_VNC" ]; then
>> +       QEMU_OPTIONS="$QEMU_OPTIONS -vnc :5"
>> +else
>> +       # When emulating a serial console, tell the kernel to use it as well
>> +       QEMU_OPTIONS="$QEMU_OPTIONS -nographic"
>> +       KERNEL_APPEND="$KERNEL_APPEND console=$SERIAL earlyprintk=serial"
>> +       MON_STDIO=1
>> +       require_config "$SERIAL_KCONFIG"
>> +fi
>> +
>> +if [ "$ROOTFS" ]; then
>> +       # Using rootfs with 9p
>> +       require_config "NET_9P_VIRTIO"
>> +       KERNEL_APPEND="$KERNEL_APPEND \
>> +root=/dev/root rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p"
>> +
>> +#Usage: -virtfs fstype,path=/share_path/,security_model=[mapped|passthrough|none],mount_tag=tag.
>> +
>> +
>> +       QEMU_OPTIONS="$QEMU_OPTIONS \
>> +-virtfs local,id=root,path=$ROOTFS,mount_tag=root,security_model=passthrough \
>> +-device virtio-9p-pci,fsdev=root,mount_tag=/dev/root"
>> +fi
>> +
>> +[ "$SMP" ] || SMP=1
>> +
>> +# User append args come last
>> +KERNEL_APPEND="$KERNEL_APPEND $KERNEL_APPEND2"
>> +
>> +############### Execution #################
>> +
>> +QEMU_OPTIONS="$QEMU_OPTIONS -smp $SMP"
>> +
>> +echo "
>> +       ################# Linux QEMU launcher #################
>> +
>> +This script executes your currently built Linux kernel using QEMU. If KVM is
>> +available, it will also use KVM for fast virtualization of your guest.
>> +
>> +The intent is to make it very easy to run your kernel. If you need to do more
>> +advanced things, such as passing through real devices, please use QEMU command
>> +line options and add them to the $BASENAME command line using --.
>> +
>> +This tool is for simplicity, not world dominating functionality coverage.
>> +(just a hobby, won't be big and professional like libvirt)
>> +
>> +"
>> +
>> +if [ "$MON_STDIO" ]; then
>> +       echo "\
>> +### Your guest is bound to the current foreground shell. To quit the guest, ###
>> +### please use Ctrl-A x                                                     ###
>> +"
>> +fi
>> +
>> +echo "  Executing: $QEMU_BIN $QEMU_OPTIONS -append \"$KERNEL_APPEND\""
> 
> This line does not match [1] below.
> 
>> +echo
>> +
>> +GDB_PID=
>> +if [ "$USE_GDB" -a "$DISPLAY" -a -x "$(which xterm)" -a -e "$(which gdb)" ]; then
>> +       # Run a gdb console in parallel to the kernel
>> +
>> +       # XXX find out if port is in use
>> +       PORT=$$
> 
> $$ could be <1024.

Yup. Fixed. It can still overflow, but let's hope that doesn't happen :(. We need a bit more logic here if we get more than 32k PIDs (plus, ports could be busy). Maybe we should listen on a UNIX socket?

> 
>> +       xterm -T "$BASENAME" -e "sleep 2; gdb vmlinux -ex 'target remote localhost:$PORT' -ex c" &
> 
> But the gnomes might not have xterms but instead gterms and so on.
> Then there are wrappers like x-terminal-emulator on some distros.

Yeah, but that's Debian only FWIW. I don't think there's a good way of determining which terminal people have available and xterm should be easily installable by everyone and does the job. So I nailed it down to that for now.

However if you find a nicer way, please let me know!

> 
>> +       GDB_PID=$!
>> +       QEMU_OPTIONS="$QEMU_OPTIONS -gdb tcp::$PORT"
>> +fi
>> +
>> +$QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND" "$@"
> 
> [1]

Alrighty, fixed :).


Alex

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Andreas Färber]

Am 06.11.2011 02:35, schrieb Alexander Graf:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just built actually works.
> 
> Fortunately, QEMU can do that today already! The only piece that was
> missing was the "simple" piece of the equation, so here is a script
> that wraps around QEMU and executes a kernel you just built.
> 
> If you do have KVM around and are not cross-compiling, it will use
> KVM. But if you don't, you can still fall back to emulation mode and
> at least check if your kernel still does what you expect. I only
> implemented support for s390x and ppc there, but it's easily extensible
> to more platforms, as QEMU can emulate (and virtualize) pretty much
> any platform out there.
> 
> If you don't have qemu installed, please do so before using this script. Your
> distro should provide a package for it (might even call it "kvm"). If not,
> just compile it from source - it's not hard!
> 
> To quickly get going, just execute the following as user:
> 
>     $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash

Path needs updating.

> 
> This will drop you into a shell on your rootfs.
> 
> Happy hacking!
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> 
> ---

> diff --git a/tools/testing/run-qemu/run-qemu.sh b/tools/testing/run-qemu/run-qemu.sh
> new file mode 100755
> index 0000000..70f194f
> --- /dev/null
> +++ b/tools/testing/run-qemu/run-qemu.sh

> +# Try to find the KVM accelerated QEMU binary
> +
> +[ "$ARCH" ] || ARCH=$(uname -m)
> +case $ARCH in
> +x86_64)
> +	KERNEL_BIN=arch/x86/boot/bzImage
> +	# SUSE and Red Hat call the binary qemu-kvm
> +	[ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null)
> +
> +	# Debian and Gentoo call it kvm
> +	[ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null)
> +
> +	# QEMU's own build system calls it qemu-system-x86_64
> +	[ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-x86_64 2>/dev/null)
> +	;;
> +i*86)
> +	KERNEL_BIN=arch/x86/boot/bzImage
> +	# SUSE and Red Hat call the binary qemu-kvm
> +	[ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-kvm 2>/dev/null)
> +
> +	# Debian and Gentoo call it kvm
> +	[ "$QEMU_BIN" ] || QEMU_BIN=$(which kvm 2>/dev/null)
> +
> +	KERNEL_BIN=arch/x86/boot/bzImage

Copy&paste?

> +	# i386 version of QEMU

QEMU's own build system calls it qemu-system-i386 now. :)

> +	[ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu 2>/dev/null)

We should first test for qemu-system-i386, then fall back to old qemu.

Andreas

P.S. You're still ahead of time...


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Anthony Liguori]

On 11/06/2011 10:50 AM, Avi Kivity wrote:
> On 11/06/2011 06:35 PM, Pekka Enberg wrote:
>>>> The difference here is that although I feel Alex's script is a
>>>> pointless project, I'm in no way opposed to merging it in the tree if
>>>> people use it and it solves their problem. Some people seem to be
>>>> violently opposed to merging the KVM tool and I'm having difficult
>>>> time understanding why that is.
>>>
>>> One of the reasons is that if it is merge, anyone with a #include
>>> <linux/foo.h>  will line up for the next merge window, wanting in.  The
>>> other is that anything in the Linux source tree might gain an unfair
>>> advantage over out-of-tree projects (at least that's how I read Jan's
>>> comment).
>>
>> Well, having gone through the process of getting something included so
>> far, I'm not at all worried that there's going to be a huge queue of
>> "#include<linux/foo.h>" projects if we get in...
>>
>> What kind of unfair advantage are you referring to? I've specifically
>> said that the only way for KVM tool to become a reference
>> implementation would be that the KVM maintainers take the tool through
>> their tree. As that's not going to happen, I don't see what the
>> problem would be.
>
> I'm not personally worried about it either (though in fact a *minimal*
> reference implementation might not be a bad idea).  There's the risk of
> getting informed in-depth press reviews ("Linux KVM Takes A Step Back
>  From Running Windows Guests"), or of unfairly drawing developers away
> from competing projects.

I don't think that's really a concern.  Competition is a good thing.  QEMU is a 
large code base that a lot of people rely upon.  It's hard to take big risks in 
a project like QEMU because the consequences are too high.

OTOH, a project like KVM tool can take a lot of risks.  They've attempted a very 
different command line syntax and they've put a lot of work into making 
virtio-9p a main part of the interface.

If it turns out that these things end up working out well for them, then it 
becomes something we can copy in QEMU.  If not, then we didn't go through the 
train wreck of totally changing CLI syntax only to find it was the wrong syntax.

I'm quite happy with KVM tool and hope they continue working on it.  My only 
real wish is that they wouldn't copy QEMU so much and would try bolder things 
that are fundamentally different from QEMU.

Regards,

Anthony Liguori

>

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Anthony Liguori]

On 11/06/2011 07:06 AM, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity<avi@redhat.com>  wrote:
>> You say that kvm-tool's scope is broader than Alex's script, therefore
>> the latter is pointless.
>
> I'm saying that Alex's script is pointless because it's not attempting
> to fix the real issues. For example, we're trying to make make it as
> easy as possible to setup a guest and to be able to access guest data
> from the host. Alex's script is essentially just a simplified QEMU
> "front end" for kernel developers.
>
> That's why I feel it's a pointless thing to do.
>
> On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity<avi@redhat.com>  wrote:
>> You accept that qemu's scope is broader than kvm-tool (and is a
>> superset).  That is why many people think kvm-tool is pointless.
>
> Sure. I think it's mostly people that are interested in non-Linux
> virtualization that think the KVM tool is a pointless project.
> However, some people (including myself) think the KVM tool is a more
> usable and hackable tool than QEMU for Linux virtualization.

There are literally dozens of mini operating systems that exist for exactly the 
same reason that you describe above.  They are smaller and easier to hack on 
than something like Linux.

Regards,

Anthony Liguori

>
> The difference here is that although I feel Alex's script is a
> pointless project, I'm in no way opposed to merging it in the tree if
> people use it and it solves their problem. Some people seem to be
> violently opposed to merging the KVM tool and I'm having difficult
> time understanding why that is.
>
>                          Pekka
>

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> I'm quite happy with KVM tool and hope they continue working on it.  My only
> real wish is that they wouldn't copy QEMU so much and would try bolder
> things that are fundamentally different from QEMU.

Hey, right now our only source of crazy ideas is Ingo and I think he's
actually a pretty conservative guy when it comes to technology. Avi
has expressed some crazy ideas in the past but they require switching
away from C and that's not something we're interested in doing. ;-)

                        Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Ted Ts'o]

On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
> I'm quite happy with KVM tool and hope they continue working on it.
> My only real wish is that they wouldn't copy QEMU so much and would
> try bolder things that are fundamentally different from QEMU.

My big wish is that they don't try to merge the KVM tool into the
kernel code.  It's a separate userspace project, and there's no reason
for it to be bundled with kernel code.  It just makes the kernel
sources larger.  The mere fact that qemu-kvm exists means that the KVM
interface has to remain backward compatible; it *is* an ABI.

So integrating kvm-tool into the kernel isn't going to work as a free
pass to make non-backwards compatible changes to the KVM user/kernel
interface.  Given that, why bloat the kernel source tree size?

Please, keep the kvm-tool sources as a separate git tree.

	     	 	  	       		- Ted

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
>> I'm quite happy with KVM tool and hope they continue working on it.
>> My only real wish is that they wouldn't copy QEMU so much and would
>> try bolder things that are fundamentally different from QEMU.

On Sun, Nov 6, 2011 at 8:31 PM, Ted Ts'o <tytso@mit.edu> wrote:
> My big wish is that they don't try to merge the KVM tool into the
> kernel code.  It's a separate userspace project, and there's no reason
> for it to be bundled with kernel code.  It just makes the kernel
> sources larger.  The mere fact that qemu-kvm exists means that the KVM
> interface has to remain backward compatible; it *is* an ABI.
>
> So integrating kvm-tool into the kernel isn't going to work as a free
> pass to make non-backwards compatible changes to the KVM user/kernel
> interface.  Given that, why bloat the kernel source tree size?

Ted, I'm confused. Making backwards incompatible ABI changes has never
been on the table. Why are you bringing it up?

                        Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 8:54 PM, Pekka Enberg <penberg@kernel.org> wrote:
>> So integrating kvm-tool into the kernel isn't going to work as a free
>> pass to make non-backwards compatible changes to the KVM user/kernel
>> interface.  Given that, why bloat the kernel source tree size?
>
> Ted, I'm confused. Making backwards incompatible ABI changes has never
> been on the table. Why are you bringing it up?

And btw, KVM tool is not a random userspace project - it was designed
to live in tools/kvm from the beginning. I've explained the technical
rationale for sharing kernel code here:

https://lkml.org/lkml/2011/11/4/150

Please also see Ingo's original rant that started the project:

http://thread.gmane.org/gmane.linux.kernel/962051/focus=962620

                        Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Ted Ts'o]

On Sun, Nov 06, 2011 at 08:58:20PM +0200, Pekka Enberg wrote:
> > Ted, I'm confused. Making backwards incompatible ABI changes has never
> > been on the table. Why are you bringing it up?
> 
> And btw, KVM tool is not a random userspace project - it was designed
> to live in tools/kvm from the beginning. I've explained the technical
> rationale for sharing kernel code here:
> 
> https://lkml.org/lkml/2011/11/4/150
> 
> Please also see Ingo's original rant that started the project:
> 
> http://thread.gmane.org/gmane.linux.kernel/962051/focus=962620

Because I don't buy any of these arguments.  We have the same kernel
developers working on xfs and xfsprogs, ext4 and e2fsprogs, btrfs and
btrfsprogs, and we don't have those userspace projects in the kernel
source tree.

The only excuse I can see is a hope to make random changes to the
kernel and userspace tools without having to worry about compatibility
problems, which is an argument I've seen with perf (that you have to
use the same version of perf as the kernel version, which to me is bad
software engineering).  And that's why I pointed out that you can't do
that with KVM, since we have out-of-tree userspace users, namely
qemu-kvm.

The rest of the arguments are arguments for a new effort, which is
fine --- but not an excuse for putting in the kernel source tree.

     	     	    	       	       - Ted

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Anthony Liguori]

On 11/06/2011 12:09 PM, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> I'm quite happy with KVM tool and hope they continue working on it.  My only
>> real wish is that they wouldn't copy QEMU so much and would try bolder
>> things that are fundamentally different from QEMU.
>
> Hey, right now our only source of crazy ideas is Ingo and I think he's
> actually a pretty conservative guy when it comes to technology. Avi
> has expressed some crazy ideas in the past but they require switching
> away from C and that's not something we're interested in doing. ;-)

Just a couple random suggestions:

- Drop SDL/VNC.  Make a proper Cairo GUI with a full blown GTK interface.  Don't 
rely on virt-manager for this.  Not that I have anything against virt-manager 
but there are many layers between you and the end GUI if you go that route.

- Sandbox the device model from day #1.  The size of the Linux kernel interface 
is pretty huge and as a hypervisor, it's the biggest place for improvement from 
a security perspective.  We're going to do sandboxing in QEMU, but it's going to 
be difficult.  It would be much easier for you given where you're at.

Regards,

Anthony Liguori

>
>                          Pekka
>

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, 6 Nov 2011, Ted Ts'o wrote:
> The only excuse I can see is a hope to make random changes to the
> kernel and userspace tools without having to worry about compatibility
> problems, which is an argument I've seen with perf (that you have to
> use the same version of perf as the kernel version, which to me is bad
> software engineering).  And that's why I pointed out that you can't do
> that with KVM, since we have out-of-tree userspace users, namely
> qemu-kvm.

I've never heard ABI incompatibility used as an argument for perf. Ingo?

As for the KVM tool, merging has never been about being able to do ABI 
incompatible changes and never will be. I'm still surprised you even 
brought this up because I've always been one to _complain_ about people 
breaking the ABI - not actually breaking it (at least on purpose).

 			Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Anthony,

On Sun, 6 Nov 2011, Anthony Liguori wrote:
> - Drop SDL/VNC.  Make a proper Cairo GUI with a full blown GTK interface. 
> Don't rely on virt-manager for this.  Not that I have anything against 
> virt-manager but there are many layers between you and the end GUI if you go 
> that route.

Funny that you should mention this. It was actually what I started out 
with. I went for SDL because it was a low-hanging fruit after the VNC 
patches which I didn't do myself.

However, it was never figured out if there was going to be a virtio 
transport for GPU commands:

http://lwn.net/Articles/408831/

On Sun, 6 Nov 2011, Anthony Liguori wrote:
> - Sandbox the device model from day #1.  The size of the Linux kernel 
> interface is pretty huge and as a hypervisor, it's the biggest place for 
> improvement from a security perspective.  We're going to do sandboxing in 
> QEMU, but it's going to be difficult.  It would be much easier for you given 
> where you're at.

Completely agreed. I think Sasha is actually starting to work on this. See 
the "Secure KVM" thread on kvm@.

 			Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Sasha Levin]

On Mon, Nov 7, 2011 at 12:23 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>  Hi,
>
>> It's not just about code, it's as much about culture and development process.
>
> Indeed.  The BSDs have both kernel and the base system in a single
> repository.  There are probably good reasons for (and against) it.
>
> In Linux we don't have that culture.  No tool (except perf) lives in the
> kernel repo.  I fail to see why kvm-tool is that much different from
> udev, util-linux, iproute, filesystem tools, that it should be included.

tools/power was merged in just 2 versions ago, do you think that
merging that was a mistake?

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Kevin Wolf]

Am 06.11.2011 19:31, schrieb Ted Ts'o:
> On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
>> I'm quite happy with KVM tool and hope they continue working on it.
>> My only real wish is that they wouldn't copy QEMU so much and would
>> try bolder things that are fundamentally different from QEMU.
> 
> My big wish is that they don't try to merge the KVM tool into the
> kernel code.  It's a separate userspace project, and there's no reason
> for it to be bundled with kernel code.  It just makes the kernel
> sources larger. 

In fact, the reverse is true as well: It makes kvm-tool's sources
larger. Instead on just cloning a small repository I need to clone the
whole kernel repository, even though I'm not a kernel developer and
don't intend to touch anything but tools/kvm.

Not too bad for me as I have a kernel repository lying around anyway and
I can share most of the content, but there are people who don't. Still,
having an additional 1.2 GB repository just for ~1 MB in which I'm
really interested doesn't make me too happy. And dealing with a huge
repository also means that even git becomes slower (which means, I had
to turn off some functionality for my shell prompt in this repo, as I
didn't like waiting for much more than a second or two)

Makes it a lot less hackable for me unless you want to restrict the set
of potential developers to Linux kernel developers...

Kevin

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, 7 Nov 2011, Kevin Wolf wrote:
> Makes it a lot less hackable for me unless you want to restrict the set
> of potential developers to Linux kernel developers...

We're not restricting potential developers to Linux kernel folks. We're 
making it easy for them because we believe that the KVM tool is a 
userspace component that requires the kind of low-level knowledge Linux 
kernel developers have.

I think you're looking at the KVM tool with your QEMU glasses on without 
realizing that there's no point in comparing the two: we only support 
Linux on Linux and we avoid hardware emulation as much as possible. So 
what makes sense for QEMU, doesn't necessarily translate to the KVM tool 
project.

 			Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Kevin Wolf]

Am 07.11.2011 12:38, schrieb Pekka Enberg:
> On Mon, 7 Nov 2011, Kevin Wolf wrote:
>> Makes it a lot less hackable for me unless you want to restrict the set
>> of potential developers to Linux kernel developers...
> 
> We're not restricting potential developers to Linux kernel folks. We're 
> making it easy for them because we believe that the KVM tool is a 
> userspace component that requires the kind of low-level knowledge Linux 
> kernel developers have.
> 
> I think you're looking at the KVM tool with your QEMU glasses on without 
> realizing that there's no point in comparing the two: we only support 
> Linux on Linux and we avoid hardware emulation as much as possible. So 
> what makes sense for QEMU, doesn't necessarily translate to the KVM tool 
> project.

I'm not comparing anything. I'm not even referring to the virtualization
functionality of it. It could be doing anything else and it wouldn't
make a difference.

For KVM tool I am not much more than a mere user. Trying it out was
tedious for me, as it is for anyone else who isn't a kernel developer.
That's all I'm saying.

Making things easier for some kernel developers but ignoring that at the
same time it makes things harder for users I consider a not so clever
move. Just wanted to point that out; feel free to ignore it, your
priorities are probably different.

Kevin

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Avi Kivity]

On 11/07/2011 12:30 PM, Sasha Levin wrote:
> On Mon, Nov 7, 2011 at 12:23 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >  Hi,
> >
> >> It's not just about code, it's as much about culture and development process.
> >
> > Indeed.  The BSDs have both kernel and the base system in a single
> > repository.  There are probably good reasons for (and against) it.
> >
> > In Linux we don't have that culture.  No tool (except perf) lives in the
> > kernel repo.  I fail to see why kvm-tool is that much different from
> > udev, util-linux, iproute, filesystem tools, that it should be included.
>
> tools/power was merged in just 2 versions ago, do you think that
> merging that was a mistake?

Things like tools/power may make sense, most of the code is tied to the
kernel interfaces.  tools/kvm is 20k lines and is likely to be 40k+
lines or more before it is generally usable.  The proportion of the code
that talks to the kernel is quite small.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Avi,

On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity <avi@redhat.com> wrote:
>> tools/power was merged in just 2 versions ago, do you think that
>> merging that was a mistake?
>
> Things like tools/power may make sense, most of the code is tied to the
> kernel interfaces.  tools/kvm is 20k lines and is likely to be 40k+
> lines or more before it is generally usable.  The proportion of the code
> that talks to the kernel is quite small.

So what do you think about perf then? The amount of code that talks to
the kernel is much smaller than that of the KVM tool.

                        Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Ted Ts'o]

On Mon, Nov 07, 2011 at 02:29:45PM +0200, Pekka Enberg wrote:
> So what do you think about perf then? The amount of code that talks to
> the kernel is much smaller than that of the KVM tool.

I think it's a mess, because it's never clear whether perf needs to be
upgraded when I upgrade the kernel, or vice versa.  This is why I keep
harping on the interface issues.

Fortunately it seems less likely (since perf doesn't run with
privileges) that security fixes will need to be released for perf, but
if it did, given the typical regression testing requirements that many
distributions have, and given that most distro packaging tools assume
that all binaries from a single source package come from a single
version of that source package, I predict you will hear screams from
the distro release engineers.

And by the way, there are use cases, where the guest OS kernel and
root on the guest OS are not available to the untrusted users, where
the userspace KVM program would be part of the security perimeter, and
were security releases to the KVM part of the tool might very well be
necessary, and it would be unfortunate if that forced the release of
new kernel packages each time security fixes are needed to the
kvm-tool userspace.  Might kvm-tool be more secure than qemu?  Quite
possibly, given that it's going to do less than qemu.  But please note
that I've not been arguing that kvm-tool shouldn't be done; just that
it not be included in the kernel sources.

Just as sparse is not bundled into the kernel sources, for crying out
loud!

						- Ted

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Avi Kivity]

On 11/07/2011 02:29 PM, Pekka Enberg wrote:
> Hi Avi,
>
> On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity <avi@redhat.com> wrote:
> >> tools/power was merged in just 2 versions ago, do you think that
> >> merging that was a mistake?
> >
> > Things like tools/power may make sense, most of the code is tied to the
> > kernel interfaces.  tools/kvm is 20k lines and is likely to be 40k+
> > lines or more before it is generally usable.  The proportion of the code
> > that talks to the kernel is quite small.
>
> So what do you think about perf then? The amount of code that talks to
> the kernel is much smaller than that of the KVM tool.

Maybe it's outgrown the kernel repo too.  Certainly something that has
perl and python integration, a TUI, and one day hopefully a GUI, doesn't
really need the kernel sources.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Anthony Liguori]

On 11/07/2011 05:57 AM, Ingo Molnar wrote:
>
> * Pekka Enberg<penberg@cs.helsinki.fi>  wrote:
>
>> On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
>>>> It's not just about code, it's as much about culture and development process.
>>>
>>> Indeed.  The BSDs have both kernel and the base system in a single
>>> repository.  There are probably good reasons for (and against) it.
>>>
>>> In Linux we don't have that culture.  No tool (except perf) lives
>>> in the kernel repo.  I fail to see why kvm-tool is that much
>>> different from udev, util-linux, iproute, filesystem tools, that
>>> it should be included.
>>
>> You seem to think perf is an exception - I think it's going to be
>> the future norm for userspace components that are very close to the
>> kernel. That's in fact what Ingo was arguing for when he suggested
>> QEMU to be merged to the kernel tree.
>
> Yep, and the answer i got from the Qemu folks when i suggested that
> merge was a polite "buzz off", along the lines of: "We don't want to
> do that, but feel free to write your own tool, leave Qemu alone."

At least it was polite :-)

>
> Now that people have done exactly that some Qemu folks not only have
> changed their objection from "write your own tool" to "erm, write
> your own tool but do it the way *we* prefer you to do it" - they also
> started contributing *against* the KVM tool with predictable, once
> every 3 months objections against its upstream merge...
>
> That's not very nice and not very constructive.

I think it's fair to have an objection to upstream merge but I think these 
threads are not terribly constructive right now as it's just rehashing the same 
arguments.

I've been thinking about the idea of merging more userspace tools into the 
kernel.  I understand the basic reasoning.  The kernel has a strong, established 
development process.  It has good infrastructure and a robust hierarchy of 
maintainers.

Good infrastructure can make a big difference to the success of a project. 
Expanding the kernel infrastructure to more projects does seem like an obvious 
thing to do when you think about it in that way.

The approach other projects have taken to this is to form a formal incubator. 
Apache is a good example of this.  There are clear (written) rules about what it 
takes for a project to join.  Once a project joins, there's a clear governance 
structure.  The project gets to consume all of the Apache infrastructure resources.

Other foundations have a release cadence to ensure that multiple components form 
a cohesive individual release (oVirt).

I think you are trying to do this in a more organic way by just merging things 
into the main git tree.  Have you thought about creating a more formal kernel 
incubator program?

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Vince Weaver]

On Mon, 7 Nov 2011, Pekka Enberg wrote:

> I've never heard ABI incompatibility used as an argument for perf. Ingo?

Never overtly.  They're too clever for that.

In any case, as a primary developer of a library (PAPI) that uses the 
perf_events ABI I have to say that having perf in the kernel has been a 
*major* pain for us.

Unlike the perf developers, we *do* have to maintain backwards 
compatability.  And we have a lot of nasty code in PAPI to handle this.
Entirely because the perf_events ABI is not stable.  It's mostly stable, 
but there are enough regressions to be a pain.

It's problem enough that there's no way to know what version of the 
perf_event abi you are running against and we have to guess based on 
kernel version.  This gets "fun" because all of the vendors have 
backported seemingly random chunks of perf_event code to their older 
kernels.

And it often does seem as the perf developers don't care when something 
breaks in perf_events if it doesn't affect perf users.

For example, the new NMI watchdog severely breaks perf_event event 
allocation if you are using FORMAT_GROUP.  perf doesn't use this though, 
so none of the kernel developers seem to care.  And unless I can quickly 
come up with a patch as an outsider, a few kernel versions will go by and 
the kernel devs will declare "well it was broken so long, now we don't 
have to fix it".  Fun.

Vince

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Ingo Molnar]

* Vince Weaver <vince@deater.net> wrote:

> On Mon, 7 Nov 2011, Pekka Enberg wrote:
> 
> > I've never heard ABI incompatibility used as an argument for 
> > perf. Ingo?

Correct, the ABI has been designed in a way to make it really hard to 
break the ABI via either directed backports or other mess-ups.

The ABI is both backwards *and* forwards ABI compatible, which is 
very rare amongst Linux ABIs.

For frequently used tools, such as perf, there's no ABI compatibility 
problem in practice: using newer perf on older kernels is pretty 
common. Using older perf on new kernels is rarer, but that generally 
works too.

In hindsight being in the kernel repo made it *easier* for perf to 
implement a good, stable ABI while also keeping a very high rate of 
change of the subsystem: changes are more 'concentrated' and people 
can stay focused on the ball to extend the ABI in sensible ways 
instead of struggling with project boundary artifacts.

I think we needed to do only one revert along the way in the past two 
years, to fix an unintended ABI breakage in PowerTop. Considering the 
total complexity of the perf ABI our compatibility track record is 
*very* good.

> Never overtly.  They're too clever for that.

Pekka, Vince has meanwhile become the resident perf critic on lkml, 
always in it when it comes to some perf-bashing:

> In any case, as a primary developer of a library (PAPI) that uses 
> the perf_events ABI I have to say that having perf in the kernel 
> has been a *major* pain for us.

... and you have argued against perf from the very first day on, when 
you were one of the perfmon developers - and IMO in hindsight you've 
been repeatedly wrong about most of your design arguments.

> Unlike the perf developers, we *do* have to maintain backwards 
> compatability. [...]

We do too, i use new perf on older distro kernels all the time. If 
you see a breakage of functionality that tools use and report in a 
timely fashion then please report it.

> [...] And we have a lot of nasty code in PAPI to handle this. 
> Entirely because the perf_events ABI is not stable.  It's mostly 
> stable, but there are enough regressions to be a pain.

You are blaming the wrong guys really.

The PAPI project has the (fundamental) problem that you are still 
doing it in the old-style sw design fashion, with many months long 
delays in testing, and then you are blaming the problems you 
inevitably meet with that model on *us*.
 
There was one PAPI incident i remember where it took you several 
*months* to report a regression in a regular PAPI test-case (no 
actual app affected as far as i know). No other tester ever ran the 
PAPI testcases so nobody else reported it.

Moving perf out of the kernel would make that particular situation 
*worse*, by further increasing the latency of fixes and by further 
increasing the risk of breakages.

Sorry, but you are trying to "fix" perf by dragging it down to your 
bad level of design and we will understandably resist that ...

> It's problem enough that there's no way to know what version of the 
> perf_event abi you are running against and we have to guess based 
> on kernel version.  This gets "fun" because all of the vendors have 
> backported seemingly random chunks of perf_event code to their 
> older kernels.

The ABI design allows for that kind of flexible extensibility, and 
it's one of its major advantages.

What we *cannot* protect against is you relying on obscure details of 
the ABI without adding it to 'perf test' and then not testing the 
upstream kernel in a timely enough fashion either ...

Nobody but you tests PAPI so you need to become *part* of the 
upstream development process, which releases a new upstream kernel 
every 3 months.

> And it often does seem as the perf developers don't care when 
> something breaks in perf_events if it doesn't affect perf users.

I have to reject your slander, both Peter, Arnaldo and me care deeply 
about fixing regressions and i've personally applied fixes out of 
order that addressed some sort of PAPI problem - whenever you chose 
to report them.

Vince, you are wrong and you have also become somewhat malicious in 
your arguments - please stop it.

> For example, the new NMI watchdog severely breaks perf_event event 
> allocation if you are using FORMAT_GROUP.  perf doesn't use this 
> though, so none of the kernel developers seem to care.  And unless 
> I can quickly come up with a patch as an outsider, a few kernel 
> versions will go by and the kernel devs will declare "well it was 
> broken so long, now we don't have to fix it".  Fun.

Face it, the *real* problem is that beyond yourself very few people 
who use a new kernel use PAPI and your long latency of testing 
exposes you to breakages in a much more agile subsystem such as perf. 
Please fix that instead of blaming it on others.

Also, as i mentioned it several times before, you are free to add an 
arbitrary number of ABI test-cases to 'perf test' and we can promise 
that we run that. Right now it consists of a few tests:

 $ perf test
 1: vmlinux symtab matches kallsyms: Ok

 2: detect open syscall event: Ok
 3: detect open syscall event on all cpus: Ok
 4: read samples using the mmap interface: Ok

... but we do not object to adding testcases for functionality used 
by PAPI.

The usual ABI rules also apply: we'll revert everything that breaks 
the ABI - but for that you need to report it *in time*, not timed one 
day before the next -stable release like you did it last time around 
...

So there's several ways of how you could help push your own interests 
into the kernel project.

Thanks,

	Ingo

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, 7 Nov 2011, Pekka Enberg wrote:
>> I've never heard ABI incompatibility used as an argument for perf. Ingo?

On Mon, Nov 7, 2011 at 7:03 PM, Vince Weaver <vince@deater.net> wrote:
> Never overtly.  They're too clever for that.

If you want me to take you seriously, spare me from the conspiracy theories, OK?

I'm sure perf developers break the ABI sometimes - that happens
elsewhere in the kernel as well. However, Ted claimed that perf
developers use tools/perf as an excuse to break the ABI _on purpose_
which is something I have hard time believing.

Your snarky remarks doesn't really help this discussion either. It's
apparent from the LKML discussions that you're more interested in
arguing with the perf developers rather than helping them.

                        Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Frank Ch. Eigler]

Ingo Molnar <mingo@elte.hu> writes:

> [...]
>> It's problem enough that there's no way to know what version of the 
>> perf_event abi you are running against and we have to guess based 
>> on kernel version.  This gets "fun" because all of the vendors have 
>> backported seemingly random chunks of perf_event code to their 
>> older kernels.
>
> The ABI design allows for that kind of flexible extensibility, and 
> it's one of its major advantages.
>
> What we *cannot* protect against is you relying on obscure details of 
> the ABI [...]

Is there some documentation that clearly spells out which parts of the
perf syscall userspace ABI are "obscure" and thus presumably
changeable?

> [...]  The usual ABI rules also apply: we'll revert everything that
> breaks the ABI - but for that you need to report it *in time* [...]

If the ABI is so great in its flexible extensibility, how come it
can't be flexibly extended without having to passing the burden of
compatibility testing & reversion-yawping to someone else?


- FChE

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, 7 Nov 2011, Frank Ch. Eigler wrote:
>> The ABI design allows for that kind of flexible extensibility, and
>> it's one of its major advantages.
>>
>> What we *cannot* protect against is you relying on obscure details of
>> the ABI [...]
>
> Is there some documentation that clearly spells out which parts of the
> perf syscall userspace ABI are "obscure" and thus presumably
> changeable?

That's actually something the KVM and virtio folks have done a great job 
with IMHO. Both ABIs are documented pretty extensively and the specs are 
kept up to date.

I guess for perf ABI, "perf test" is the closest thing to a specification 
so if your application is using something that's not covered by it, you 
might be in trouble.

 			Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Ted Ts'o]

On Mon, Nov 07, 2011 at 09:53:28PM +0200, Pekka Enberg wrote:
> 
> I'm sure perf developers break the ABI sometimes - that happens
> elsewhere in the kernel as well. However, Ted claimed that perf
> developers use tools/perf as an excuse to break the ABI _on purpose_
> which is something I have hard time believing.

I remember an assertion, probably a year or two ago, probably at the
previous year's kernel summit, that one of the reasons for having the
perf code inline in the kernel was so that synchronized changes could
be made to both the kernel and userspace tool together.  So it's not a
matter of breaking the ABI _on_ _purpose_, it's an assertion that
there is no ABI at all.  Since the perf tool and the kernel tool have
to be built together, so long as a user does that, no harm, no foul.
Recall that Linus has said that he doesn't care about whether or not
something is an ABI; he only care if users code don't perceive
breakage.  If they didn't perceive breakage, then it doesn't matter if
an interface is changed.

So the real question is whether or not this was an excuse to break the
ABI, but whether or not the perf developers acknowledge there is an
ABI at all, and whether it's OK for other developers to depend on the
syscall interface or not.  Actually, though, it shouldn't matter,
because intentions don't matter.

Recall the powertop/ftrace case.  If you expose an interface, and
people start using that interface, then you can't break them, period.
So as far as Vince is concerned, if you have a userspace library which
depends on the perf interface, then you should try out the kernel
after each merge window, and if your library breaks, you should
complain to Ingo and Linus directly, and request that the commit which
broke your tool to be reverted --- because that's the rule; no
breakage is allowed.

As far as kvm-tool being in the kernel, I still don't see particularly
valid arguments for why it should be in the kernel.  It can't be the
perf argument of "we can make simultaneous changes in the userspace
and kernel code", because if those changes break qemu-kvm, then a
complaint to Linus will cause the problem code to be reverted.

As far as the code using the same coding conventions and naming
conventions as the kernel, that to me isn't a particular strong
argument either.  E2fsprogs uses the Signed-off-by lines, and the same
coding conventions of the kernel, and it even has a slightly modified
version of two kernel source file in e2fsprogs (e2fsck/recovery.c and
e2fsck/revoke.c), plus a header file with data structures that have to
be kept in sync with the kernel header file.  But that doesn't make it
"part of the kernel", and it's not a justification for it to be
bundled with the kernel.

Personally, I consider code that runs in userspace as a pretty bright
line, as being "not kernel code", and while perhaps things like
initramfs and the crazy ideas people have had in the past of moving
stuff out of kernel/init.c into userspace might have qualified as
stuff really close to the kernel, something like kvm-tool that runs
way after boot, doesn't even come close.  Wine is another example of
another package that has lots of close kernel ties, but was also not
bundled into the kernel.

The precedent has all mainly been on the "keep the kernel separate"
side of things, and the arguments for bundling it with the kernel are
much weaker, especially since the interface is well-developed, and
there are external users of the interface which means you can't make
changes to the interface willy-nilly.

Indeed, when the perf interface was changing all the time, maybe there
was some convenience to have it be bundled with the kernel, so there
was no need to negotiate interface version numbers, et. al.  But given
how it has to link in so many user space libraries, I personally think
it's fair to ask the question whether now that it has matured, whether
it's time to move it out of the kernel source tree.

Regards,

							- Ted

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Ted Ts'o]

On Mon, Nov 07, 2011 at 10:09:34PM +0200, Pekka Enberg wrote:
> 
> I guess for perf ABI, "perf test" is the closest thing to a
> specification so if your application is using something that's not
> covered by it, you might be in trouble.

I don't believe there's ever been any guarantee that "perf test" from
version N of the kernel will always work on a version N+M of the
kernel.  Perhaps I am wrong, though. If that is a guarantee that the
perf developers are willing to stand behind, or have already made, I
would love to be corrected and would be delighted to hear that in fact
there is a stable, backwards compatible perf ABI.

Regards,

						- Ted

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Ted,

On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o <tytso@mit.edu> wrote:
> Personally, I consider code that runs in userspace as a pretty bright
> line, as being "not kernel code", and while perhaps things like
> initramfs and the crazy ideas people have had in the past of moving
> stuff out of kernel/init.c into userspace might have qualified as
> stuff really close to the kernel, something like kvm-tool that runs
> way after boot, doesn't even come close.  Wine is another example of
> another package that has lots of close kernel ties, but was also not
> bundled into the kernel.

It's not as clear line as you make it out to be.

KVM tool also has mini-BIOS code that runs in guest space. It has a
code that runs in userspace but is effectively a simple bootloader. So
it definitely doesn't fit the simple definition of "running way after
boot" (we're _booting_ the kernel too).

Linsched fits your definition but is clearly worth integrating to the
kernel tree. While you are suggesting that maybe we should move Perf
out of the tree now that it's mature, I'm pretty sure you'd agree that
it probably would not have happened if the userspace parts were
developed out of tree.

There's also spectacular failures in the kernel history where the
userspace split was enforced. For example, userspace suspend didn't
turn out the way people envisioned it at the time. We don't know how
it would have worked out if the userspace components would have been
in the tree but it certainly would have solved many if the early ABI
issues.

I guess I'm trying to argue here that there's a middle ground. I'm
willing to bet projects like klibc and unified initramfs will
eventually make it to the kernel tree because they simply make so much
sense. I'm also willing to be that the costs of moving Perf out of the
tree are simply too high to make it worthwhile.

Does that mean KVM tool should get a free pass in merging? Absolutely
not. But I do think your position is too extreme and ignores the
benefits of developing userspace tools in the kernel ecosystem which
was summed up by Anthony rather well in this thread:

https://lkml.org/lkml/2011/11/7/169

                                Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Anthony Liguori]

On 11/07/2011 03:36 PM, Pekka Enberg wrote:
> Hi Ted,
>
> On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o<tytso@mit.edu>  wrote:
>> Personally, I consider code that runs in userspace as a pretty bright
>> line, as being "not kernel code", and while perhaps things like
>> initramfs and the crazy ideas people have had in the past of moving
>> stuff out of kernel/init.c into userspace might have qualified as
>> stuff really close to the kernel, something like kvm-tool that runs
>> way after boot, doesn't even come close.  Wine is another example of
>> another package that has lots of close kernel ties, but was also not
>> bundled into the kernel.
>
> It's not as clear line as you make it out to be.
>
> KVM tool also has mini-BIOS code that runs in guest space. It has a
> code that runs in userspace but is effectively a simple bootloader. So
> it definitely doesn't fit the simple definition of "running way after
> boot" (we're _booting_ the kernel too).
>
> Linsched fits your definition but is clearly worth integrating to the
> kernel tree. While you are suggesting that maybe we should move Perf
> out of the tree now that it's mature, I'm pretty sure you'd agree that
> it probably would not have happened if the userspace parts were
> developed out of tree.
>
> There's also spectacular failures in the kernel history where the
> userspace split was enforced. For example, userspace suspend didn't
> turn out the way people envisioned it at the time. We don't know how
> it would have worked out if the userspace components would have been
> in the tree but it certainly would have solved many if the early ABI
> issues.
>
> I guess I'm trying to argue here that there's a middle ground. I'm
> willing to bet projects like klibc and unified initramfs will
> eventually make it to the kernel tree because they simply make so much
> sense. I'm also willing to be that the costs of moving Perf out of the
> tree are simply too high to make it worthwhile.
>
> Does that mean KVM tool should get a free pass in merging? Absolutely
> not. But I do think your position is too extreme and ignores the
> benefits of developing userspace tools in the kernel ecosystem which
> was summed up by Anthony rather well in this thread:
>
> https://lkml.org/lkml/2011/11/7/169

The kernel ecosystem does not have to be limited to linux.git.  There could be a 
process to be a "kernel.org project" for projects that fit a certain set of 
criteria.  These projects could all share the Linux kernel release cadence and 
have a kernel maintainer as a sponsor or something like that.

That is something that could potentially benefit things like e2fs-tools and all 
of the other tools that are tied closely to the kernel.

In fact, having a single place where users could find all of the various kernel 
related tools and helpers would probably be extremely useful.  There's no reason 
this needs to be linux.git though, this could just be a web page on kernel.org.

Regards,

Anthony Liguori

>
>                                  Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Theodore Tso]

On Nov 7, 2011, at 5:19 PM, Anthony Liguori wrote:

> 
> The kernel ecosystem does not have to be limited to linux.git.  There could be a process to be a "kernel.org project" for projects that fit a certain set of criteria.  These projects could all share the Linux kernel release cadence and have a kernel maintainer as a sponsor or something like that.
> 
> That is something that could potentially benefit things like e2fs-tools and all of the other tools that are tied closely to the kernel.

We have that already.   Packages such as e2fsprogs, xfsprogs, xfstests, sparse, git, etc., have git trees under git.kernel.org.  And I agree that's the perfect place for kvm-tool and perf.   :-)

-- Ted

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Vince Weaver]

On Mon, 7 Nov 2011, Ingo Molnar wrote:
> I think we needed to do only one revert along the way in the past two 
> years, to fix an unintended ABI breakage in PowerTop. Considering the 
> total complexity of the perf ABI our compatibility track record is 
> *very* good.

There have been more breakages, as you know.  It's just they weren't 
caught in time so they were declared to be grandfathered in rather
than fixed.

> Pekka, Vince has meanwhile become the resident perf critic on lkml, 
> always in it when it comes to some perf-bashing:

For what it's worth you'll find commits from me in the qemu tree, and I
also oppose the merge of kvm-tool into the Linux tree.

> ... and you have argued against perf from the very first day on, when 
> you were one of the perfmon developers - and IMO in hindsight you've 
> been repeatedly wrong about most of your design arguments.

I can't find an exact e-mail, but I seem to recall my arguments were that
Pentium 4 support would be hard (it was), that in-kernel generalized 
events were a bad idea (I still think that, try talking to the ARM guys 
sometime about that) and that making access to raw events hard (by not 
using a naming library) was silly.  I'm sure I probably said other things
that were eventually addressed.

> The PAPI project has the (fundamental) problem that you are still 
> doing it in the old-style sw design fashion, with many months long 
> delays in testing, and then you are blaming the problems you 
> inevitably meet with that model on *us*.

The fundamental problem with the PAPI project is that we only have 3 
full-time developers, and we have to make sure PAPI runs on about 10 
different platforms, of which perf_events/Linux is only one.

Time I waste tracking down perf_event ABI regressions and DoS bugs
takes away from actual useful userspace PAPI development.

> There was one PAPI incident i remember where it took you several 
> *months* to report a regression in a regular PAPI test-case (no 
> actual app affected as far as i know). No other tester ever ran the 
> PAPI testcases so nobody else reported it.

We have a huge userbase.  They run on some pretty amazing machines and 
do some tests that strain perf libraries to the limit.
They also tend to use distro kernels, assuming they even have moved to 
2.6.31+ kernels yet.  When these power users report problems, they aren't 
going to be against the -tip tree.

> Nobody but you tests PAPI so you need to become *part* of the 
> upstream development process, which releases a new upstream kernel 
> every 3 months.

PAPI is a free software project, with the devel tree available from CVS.
It takes maybe 15 minutes to run the full PAPI regression suite.
I encourage you or any perf developer to try it and report any issues.

I can only be so comprehensive.  I didn't find the current NMI-watchdog 
regression right away because my git tree builds didn't have it enabled.  
It wasn't until there started being 3.0 distro kernels that people started 
reporting the problem to us.

> Also, as i mentioned it several times before, you are free to add an 
> arbitrary number of ABI test-cases to 'perf test' and we can promise 
> that we run that. Right now it consists of a few tests:

as mentioned before I have my own perf_event test suite with 20+ tests.
  http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html

I do run it often.  It tends to be reactionary though, as I can only add a 
test for a bug once I know about it.

I also have more up-to date perf documentation than the kernel does:
  http://web.eecs.utk.edu/~vweaver1/projects/perf-events/programming.html

and a cpu compatability matrix:
  http://web.eecs.utk.edu/~vweaver1/projects/perf-events/support.html

I didn't really want to turn this into yet another perf flamewar.  I just 
didn't want the implication that perf being in kernel is all rainbows
and unicorns to go unchallenged.

Vince

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Ingo Molnar]

* Vince Weaver <vince@deater.net> wrote:

> On Mon, 7 Nov 2011, Ingo Molnar wrote:

> > I think we needed to do only one revert along the way in the past 
> > two years, to fix an unintended ABI breakage in PowerTop. 
> > Considering the total complexity of the perf ABI our 
> > compatibility track record is *very* good.
> 
> There have been more breakages, as you know.  It's just they 
> weren't caught in time so they were declared to be grandfathered in 
> rather than fixed.

I remember one such instance were you reported a 'regression' that 
spanned several -stable kernel releases - and unless the fix is easy 
and obvious that's the regular upstream treatment.

As Linus said it too on the recent Kernel Summit an ABI is only an 
ABI if it's actually *used*.

But there's more, you've repeatedly rejected our offer to extend 
'perf test' to cover the functionality that your library relies on. 
If you refuse to timely test newer upstream kernels while you rely on 
obscure details that nobody else uses and if you refuse to make your 
testcases more prominent it becomes *your* problem.

There's not much we can do if you refuse to test and refuse to push 
your testcases upstream ...

> > ... and you have argued against perf from the very first day on, 
> > when you were one of the perfmon developers - and IMO in 
> > hindsight you've been repeatedly wrong about most of your design 
> > arguments.
> 
> I can't find an exact e-mail, but I seem to recall my arguments 
> were that Pentium 4 support would be hard (it was), [...]

To the contrary, a single person implemented most of it, out of 
curiosity.

> [...] that in-kernel generalized events were a bad idea (I still 
> think that, try talking to the ARM guys sometime about that) [...]

To the contrary, generalized events work very well and they are one 
of the reasons why the perf tooling is so usable.

> [...] and that making access to raw events hard (by not using a 
> naming library) was silly. [...]

To the contrary, by 'making it easy' you mean 'translate hexa codes 
to vendor specific gibberish' which is hardly any better to actual 
users of the tool and gives the false appearance of being a solution.

All in one you advocated all the oprofile design mistakes and you 
have been proven thoroughly wrong by reality.

> > The PAPI project has the (fundamental) problem that you are still 
> > doing it in the old-style sw design fashion, with many months 
> > long delays in testing, and then you are blaming the problems you 
> > inevitably meet with that model on *us*.
> 
> The fundamental problem with the PAPI project is that we only have 
> 3 full-time developers, and we have to make sure PAPI runs on about 
> 10 different platforms, of which perf_events/Linux is only one.
> 
> Time I waste tracking down perf_event ABI regressions and DoS bugs 
> takes away from actual useful userspace PAPI development.

If people are not interested in even testing the basic test-suite of 
PAPI on a recent kernel then i'm afraid there must be something very 
wrong with the PAPI project structure.

Somehow that testing is not missing from the perf tool, despite it 
being a much younger and smaller project. Did you ever stop to think 
why that is so?

> > There was one PAPI incident i remember where it took you several 
> > *months* to report a regression in a regular PAPI test-case (no 
> > actual app affected as far as i know). No other tester ever ran 
> > the PAPI testcases so nobody else reported it.
> 
> We have a huge userbase.  They run on some pretty amazing machines 
> and do some tests that strain perf libraries to the limit. They 
> also tend to use distro kernels, assuming they even have moved to 
> 2.6.31+ kernels yet.  When these power users report problems, they 
> aren't going to be against the -tip tree.

Nobody expects you to test the -tip tree if you don't want to (it 
would certainly be useful to you if you are interested in PMU 
development), but there's a 2.5 months stabilization window after the 
upstream merge.

> > Nobody but you tests PAPI so you need to become *part* of the 
> > upstream development process, which releases a new upstream 
> > kernel every 3 months.
> 
> PAPI is a free software project, with the devel tree available from 
> CVS. It takes maybe 15 minutes to run the full PAPI regression 
> suite. I encourage you or any perf developer to try it and report 
> any issues.

I will fix what gets reported and neither i nor other regular kernel 
testers actually use it.

You really need to do more testing to fill that gap, expecting others 
to volunteer time into a project they don't actually use is extremely 
backwards...

> I can only be so comprehensive.  I didn't find the current 
> NMI-watchdog regression right away because my git tree builds 
> didn't have it enabled.  It wasn't until there started being 3.0 
> distro kernels that people started reporting the problem to us.
>
> > Also, as i mentioned it several times before, you are free to add 
> > an arbitrary number of ABI test-cases to 'perf test' and we can 
> > promise that we run that. Right now it consists of a few tests:
> 
> as mentioned before I have my own perf_event test suite with 20+ tests.
>   http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html

That should probably be moved into perf test. Arnaldo, any 
objections?

> I do run it often.  It tends to be reactionary though, as I can 
> only add a test for a bug once I know about it.
> 
> I also have more up-to date perf documentation than the kernel does:
>   http://web.eecs.utk.edu/~vweaver1/projects/perf-events/programming.html
> 
> and a cpu compatability matrix:
>   http://web.eecs.utk.edu/~vweaver1/projects/perf-events/support.html
> 
> I didn't really want to turn this into yet another perf flamewar.  

So why then did you launch several malicious, unprovoked, 
passive-aggressive ad hominem attacks against perf developers, like:

  "Never overtly.  They're too clever for that."

and:

  "Unlike the perf developers, we *do* have to maintain backwards
   compatability."

? They were untrue, uncalled for, unfair and outright mean-spirited.

Thanks,

	Ingo

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Arnaldo Carvalho de Melo]

Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu:
> * Vince Weaver <vince@deater.net> wrote:
> > as mentioned before I have my own perf_event test suite with 20+ tests.
> >   http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html
 
> That should probably be moved into perf test. Arnaldo, any 
> objections?

I'd gladly take patches, I even have in my TODO list for me to volunteer
time to do that at some point.

If somebody else than me or Vince wants to do that... Assuming there is
no licensing problem and Vince doesn't objects for that to be done.

I know that at least the QE team at Red Hat uses it and I hope other QE
teams do it.

- Arnaldo

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Vince Weaver]

On Tue, 8 Nov 2011, Arnaldo Carvalho de Melo wrote:

> Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu:
> > * Vince Weaver <vince@deater.net> wrote:
> > > as mentioned before I have my own perf_event test suite with 20+ tests.
> > >   http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html
>  
> > That should probably be moved into perf test. Arnaldo, any 
> > objections?
> 
> I'd gladly take patches, I even have in my TODO list for me to volunteer
> time to do that at some point.
> 
> If somebody else than me or Vince wants to do that... Assuming there is
> no licensing problem and Vince doesn't objects for that to be done.

I have no objections, though I don't really have time right now to do the 
work myself.

The test code is licensed dual GPLv2/BSD.  I should stick that in the 
package somewhere if I haven't already.

My testcases mostly are testing things necessary for proper PAPI 
functionality and are by no means complete.  There are huge
areas of perf_event functionality that are not well tested, especially
the overflow code.

Vince