* [PATCH] KVM: Add wrapper script around Qemu to test kernels
@ 2011-08-23 22:16 Alexander Graf
2011-08-24 5:19 ` Pekka Enberg
` (2 more replies)
0 siblings, 3 replies; 88+ messages in thread
From: Alexander Graf @ 2011-08-23 22:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Avi Kivity, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers, Pekka Enberg
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
^ permalink raw reply related [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-23 22:16 [PATCH] KVM: Add wrapper script around Qemu to test kernels Alexander Graf
@ 2011-08-24 5:19 ` Pekka Enberg
2011-08-24 5:31 ` Américo Wang
2011-08-24 8:25 ` Avi Kivity
2011-08-24 17:40 ` [Qemu-devel] " Blue Swirl
2 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-08-24 5:19 UTC (permalink / raw)
To: Alexander Graf
Cc: Linus Torvalds, Ingo Molnar, Avi Kivity,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers
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
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-24 5:19 ` Pekka Enberg
@ 2011-08-24 5:31 ` Américo Wang
2011-08-24 20:35 ` Alexander Graf
0 siblings, 1 reply; 88+ messages in thread
From: Américo Wang @ 2011-08-24 5:31 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar, Avi Kivity,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers
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!
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-24 5:31 ` Américo Wang
@ 2011-08-24 20:35 ` Alexander Graf
2011-08-25 3:44 ` Américo Wang
0 siblings, 1 reply; 88+ messages in thread
From: Alexander Graf @ 2011-08-24 20:35 UTC (permalink / raw)
To: Américo Wang
Cc: Pekka Enberg, Linus Torvalds, Ingo Molnar, Avi Kivity,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers
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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-24 20:35 ` Alexander Graf
@ 2011-08-25 3:44 ` Américo Wang
2011-11-05 23:47 ` Alexander Graf
0 siblings, 1 reply; 88+ messages in thread
From: Américo Wang @ 2011-08-25 3:44 UTC (permalink / raw)
To: Alexander Graf
Cc: Pekka Enberg, Linus Torvalds, Ingo Molnar, Avi Kivity,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers
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.
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-25 3:44 ` Américo Wang
@ 2011-11-05 23:47 ` Alexander Graf
0 siblings, 0 replies; 88+ messages in thread
From: Alexander Graf @ 2011-11-05 23:47 UTC (permalink / raw)
To: Américo Wang
Cc: Pekka Enberg, Linus Torvalds, Ingo Molnar, Avi Kivity,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Steven Rostedt
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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-23 22:16 [PATCH] KVM: Add wrapper script around Qemu to test kernels Alexander Graf
2011-08-24 5:19 ` Pekka Enberg
@ 2011-08-24 8:25 ` Avi Kivity
2011-08-24 9:16 ` Jan Kiszka
2011-08-24 17:40 ` [Qemu-devel] " Blue Swirl
2 siblings, 1 reply; 88+ messages in thread
From: Avi Kivity @ 2011-08-24 8:25 UTC (permalink / raw)
To: Alexander Graf
Cc: Linus Torvalds, Ingo Molnar, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers, Pekka Enberg
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.
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-24 8:25 ` Avi Kivity
@ 2011-08-24 9:16 ` Jan Kiszka
2011-08-24 21:06 ` Alexander Graf
0 siblings, 1 reply; 88+ messages in thread
From: Jan Kiszka @ 2011-08-24 9:16 UTC (permalink / raw)
To: Avi Kivity, Alexander Graf
Cc: Linus Torvalds, Ingo Molnar, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers, Pekka Enberg
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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-24 9:16 ` Jan Kiszka
@ 2011-08-24 21:06 ` Alexander Graf
0 siblings, 0 replies; 88+ messages in thread
From: Alexander Graf @ 2011-08-24 21:06 UTC (permalink / raw)
To: Jan Kiszka
Cc: Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Pekka Enberg
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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-23 22:16 [PATCH] KVM: Add wrapper script around Qemu to test kernels Alexander Graf
2011-08-24 5:19 ` Pekka Enberg
2011-08-24 8:25 ` Avi Kivity
@ 2011-08-24 17:40 ` Blue Swirl
2011-08-24 19:17 ` Avi Kivity
2011-08-24 21:17 ` Alexander Graf
2 siblings, 2 replies; 88+ messages in thread
From: Blue Swirl @ 2011-08-24 17:40 UTC (permalink / raw)
To: Alexander Graf
Cc: Linus Torvalds, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Pekka Enberg, Avi Kivity
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
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-24 17:40 ` [Qemu-devel] " Blue Swirl
@ 2011-08-24 19:17 ` Avi Kivity
2011-08-24 21:17 ` Alexander Graf
1 sibling, 0 replies; 88+ messages in thread
From: Avi Kivity @ 2011-08-24 19:17 UTC (permalink / raw)
To: Blue Swirl
Cc: Alexander Graf, Linus Torvalds, kvm@vger.kernel.org list,
qemu-devel Developers, linux-kernel@vger.kernel.org List,
Pekka Enberg
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.
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around Qemu to test kernels
2011-08-24 17:40 ` [Qemu-devel] " Blue Swirl
2011-08-24 19:17 ` Avi Kivity
@ 2011-08-24 21:17 ` Alexander Graf
1 sibling, 0 replies; 88+ messages in thread
From: Alexander Graf @ 2011-08-24 21:17 UTC (permalink / raw)
To: Blue Swirl
Cc: Linus Torvalds, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Pekka Enberg, Avi Kivity
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
^ permalink raw reply [flat|nested] 88+ messages in thread
* [PATCH] KVM: Add wrapper script around QEMU to test kernels
@ 2011-08-24 21:38 Alexander Graf
2011-11-06 13:54 ` Jan Kiszka
0 siblings, 1 reply; 88+ messages in thread
From: Alexander Graf @ 2011-08-24 21:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Avi Kivity, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers, Pekka Enberg
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\""
+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=$$
+ xterm -T "$BASENAME" -e "sleep 2; gdb vmlinux -ex 'target remote localhost:$PORT' -ex c" &
+ GDB_PID=$!
+ QEMU_OPTIONS="$QEMU_OPTIONS -gdb tcp::$PORT"
+fi
+
+$QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND" "$@"
+wait $GDB_PID &>/dev/null
+
--
1.6.0.2
^ permalink raw reply related [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-08-24 21:38 [PATCH] KVM: Add wrapper script around QEMU " Alexander Graf
@ 2011-11-06 13:54 ` Jan Kiszka
2012-05-11 13:42 ` Alexander Graf
0 siblings, 1 reply; 88+ messages in thread
From: Jan Kiszka @ 2011-11-06 13:54 UTC (permalink / raw)
To: Alexander Graf
Cc: Linus Torvalds, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Pekka Enberg, Avi Kivity
[-- Attachment #1: Type: text/plain, Size: 11644 bytes --]
On 2011-08-24 23:38, 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!
>
> 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
+ require_config "BLK_DEV_SD"
Maybe there should also be a warning if no standard FS (ext[34], btrfs,
xfs etc.) is build into the kernel.
Another thing, but that's just a recommendation for initrd-free mode:
DEVTMPFS_MOUNT
> + 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"
That should be
KERNEL_APPEND2="$KERNEL_APPEND2 $2"
> + shift
> + ;;
> + -d|--disk)
> + QEMU_OPTIONS="$QEMU_OPTIONS -drive \
> + file=$2,if=$(drive_if),cache=unsafe"
if [ $? != 0 ]; then
exit $?
fi
> + 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"
+ require_config "9P_FS"
> + 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\""
> +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=$$
> + xterm -T "$BASENAME" -e "sleep 2; gdb vmlinux -ex 'target remote localhost:$PORT' -ex c" &
> + GDB_PID=$!
> + QEMU_OPTIONS="$QEMU_OPTIONS -gdb tcp::$PORT"
> +fi
> +
> +$QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND" "$@"
> +wait $GDB_PID &>/dev/null
> +
Nice that it forks off a gdb session. I will contribute my gdb helper
script soon (module symbol loading, dmesg, per-cpu variable lookup etc.)
so that it can be loaded automatically.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 13:54 ` Jan Kiszka
@ 2012-05-11 13:42 ` Alexander Graf
2012-05-11 14:05 ` Jan Kiszka
0 siblings, 1 reply; 88+ messages in thread
From: Alexander Graf @ 2012-05-11 13:42 UTC (permalink / raw)
To: Jan Kiszka
Cc: Linus Torvalds, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Pekka Enberg, Avi Kivity
On 06.11.2011, at 14:54, Jan Kiszka wrote:
> On 2011-08-24 23:38, 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!
>>
>> 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
>
> + require_config "BLK_DEV_SD"
>
> Maybe there should also be a warning if no standard FS (ext[34], btrfs,
> xfs etc.) is build into the kernel.
>
> Another thing, but that's just a recommendation for initrd-free mode:
> DEVTMPFS_MOUNT
>
>> + 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"
>
> That should be
>
> KERNEL_APPEND2="$KERNEL_APPEND2 $2"
>
>> + shift
>> + ;;
>> + -d|--disk)
>> + QEMU_OPTIONS="$QEMU_OPTIONS -drive \
>> + file=$2,if=$(drive_if),cache=unsafe"
>
> if [ $? != 0 ]; then
> exit $?
> fi
Not sure I understand this one. There's no program executing here...
Alex
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2012-05-11 13:42 ` Alexander Graf
@ 2012-05-11 14:05 ` Jan Kiszka
0 siblings, 0 replies; 88+ messages in thread
From: Jan Kiszka @ 2012-05-11 14:05 UTC (permalink / raw)
To: Alexander Graf
Cc: Linus Torvalds, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Pekka Enberg, Avi Kivity
[-- Attachment #1: Type: text/plain, Size: 6073 bytes --]
On 2012-05-11 10:42, Alexander Graf wrote:
>
> On 06.11.2011, at 14:54, Jan Kiszka wrote:
>
>> On 2011-08-24 23:38, 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!
>>>
>>> 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
>>
>> + require_config "BLK_DEV_SD"
>>
>> Maybe there should also be a warning if no standard FS (ext[34], btrfs,
>> xfs etc.) is build into the kernel.
>>
>> Another thing, but that's just a recommendation for initrd-free mode:
>> DEVTMPFS_MOUNT
>>
>>> + 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"
>>
>> That should be
>>
>> KERNEL_APPEND2="$KERNEL_APPEND2 $2"
>>
>>> + shift
>>> + ;;
>>> + -d|--disk)
>>> + QEMU_OPTIONS="$QEMU_OPTIONS -drive \
>>> + file=$2,if=$(drive_if),cache=unsafe"
>>
>> if [ $? != 0 ]; then
>> exit $?
>> fi
>
> Not sure I understand this one. There's no program executing here...
Not sure either. Does drive_if exit the complete script when it fails?
Maybe it was related to this, give it a try again.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 88+ messages in thread
* [PATCH] KVM: Add wrapper script around QEMU to test kernels
@ 2011-11-06 1:35 Alexander Graf
2011-11-06 10:04 ` Pekka Enberg
2011-11-08 14:41 ` Avi Kivity
0 siblings, 2 replies; 88+ messages in thread
From: Alexander Graf @ 2011-11-06 1:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Avi Kivity, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers, Pekka Enberg,
Américo Wang, Blue Swirl
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
v2 -> v3:
- move to tools/testing
- fix running: message
( sorry for sending this version so late - I got caught up in
random other stuff )
---
tools/testing/run-qemu/run-qemu.sh | 338 ++++++++++++++++++++++++++++++++++++
1 files changed, 338 insertions(+), 0 deletions(-)
create mode 100755 tools/testing/run-qemu/run-qemu.sh
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
@@ -0,0 +1,338 @@
+#!/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 -n " Executing: $QEMU_BIN $QEMU_OPTIONS -append \"$KERNEL_APPEND\" "
+for i in "$@"; do
+ echo -n "\"$i\" "
+done
+echo
+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=$(( $$ + 1024 ))
+ xterm -T "$BASENAME" -e "sleep 2; gdb vmlinux -ex 'target remote localhost:$PORT' -ex c" &
+ GDB_PID=$!
+ QEMU_OPTIONS="$QEMU_OPTIONS -gdb tcp::$PORT"
+fi
+
+$QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND" "$@"
+wait $GDB_PID &>/dev/null
+
--
1.6.0.2
^ permalink raw reply related [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 1:35 Alexander Graf
@ 2011-11-06 10:04 ` Pekka Enberg
2011-11-06 10:07 ` Avi Kivity
2011-11-08 14:41 ` Avi Kivity
1 sibling, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 10:04 UTC (permalink / raw)
To: Alexander Graf
Cc: Linus Torvalds, Ingo Molnar, Avi Kivity,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
Hi Alexander,
On Sun, Nov 6, 2011 at 3:35 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.
I'm happy to see some real competition for the KVM tool in usability. ;-)
That said, while the script looks really useful for developers,
wouldn't it make more sense to put it in QEMU to make sure it's kept
up-to-date and distributions can pick it up too? (And yes, I realize
the irony here.)
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 10:04 ` Pekka Enberg
@ 2011-11-06 10:07 ` Avi Kivity
2011-11-06 10:12 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Avi Kivity @ 2011-11-06 10:07 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On 11/06/2011 12:04 PM, Pekka Enberg wrote:
> Hi Alexander,
>
> On Sun, Nov 6, 2011 at 3:35 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.
>
> I'm happy to see some real competition for the KVM tool in usability. ;-)
>
> That said, while the script looks really useful for developers,
> wouldn't it make more sense to put it in QEMU to make sure it's kept
> up-to-date and distributions can pick it up too? (And yes, I realize
> the irony here.)
Why would distributions want it? It's only useful for kernel developers.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 10:07 ` Avi Kivity
@ 2011-11-06 10:12 ` Pekka Enberg
2011-11-06 10:23 ` Avi Kivity
0 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 10:12 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On Sun, Nov 6, 2011 at 12:07 PM, Avi Kivity <avi@redhat.com> wrote:
>> I'm happy to see some real competition for the KVM tool in usability. ;-)
>>
>> That said, while the script looks really useful for developers,
>> wouldn't it make more sense to put it in QEMU to make sure it's kept
>> up-to-date and distributions can pick it up too? (And yes, I realize
>> the irony here.)
>
> Why would distributions want it? It's only useful for kernel developers.
It's useful for kernel testers too.
If this is a serious attempt in making QEMU command line suck less on
Linux, I think it makes sense to do this properly instead of adding a
niche script to the kernel tree that's simply going to bit rot over
time.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 10:12 ` Pekka Enberg
@ 2011-11-06 10:23 ` Avi Kivity
2011-11-06 11:08 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Avi Kivity @ 2011-11-06 10:23 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On 11/06/2011 12:12 PM, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 12:07 PM, Avi Kivity <avi@redhat.com> wrote:
> >> I'm happy to see some real competition for the KVM tool in usability. ;-)
> >>
> >> That said, while the script looks really useful for developers,
> >> wouldn't it make more sense to put it in QEMU to make sure it's kept
> >> up-to-date and distributions can pick it up too? (And yes, I realize
> >> the irony here.)
> >
> > Why would distributions want it? It's only useful for kernel developers.
>
> It's useful for kernel testers too.
Well, they usually have a kernel with them.
> If this is a serious attempt in making QEMU command line suck less on
> Linux, I think it makes sense to do this properly instead of adding a
> niche script to the kernel tree that's simply going to bit rot over
> time.
You misunderstand. This is an attempt to address the requirements of a
niche population, kernel developers and testers, not to improve the qemu
command line. For the majority of qemu installations, this script is
useless.
In most installations, qemu is driven by other programs, so any changes
to the command line would be invisible, except insofar as they break things.
For the occasional direct user of qemu, something like 'qemu-kvm -m 1G
/images/blah.img' is enough to boot an image. This script doesn't help
in any way.
This script is for kernel developers who don't want to bother with
setting up a disk image (which, btw, many are still required to do - I'm
guessing most kernel developers who use qemu are cross-arch). It has
limited scope and works mostly by hiding qemu features. As such it
doesn't belong in qemu.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 10:23 ` Avi Kivity
@ 2011-11-06 11:08 ` Pekka Enberg
2011-11-06 11:50 ` Avi Kivity
0 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 11:08 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
Hi Avi,
On Sun, 2011-11-06 at 12:23 +0200, Avi Kivity wrote:
> > If this is a serious attempt in making QEMU command line suck less on
> > Linux, I think it makes sense to do this properly instead of adding a
> > niche script to the kernel tree that's simply going to bit rot over
> > time.
>
> You misunderstand. This is an attempt to address the requirements of a
> niche population, kernel developers and testers, not to improve the qemu
> command line. For the majority of qemu installations, this script is
> useless.
Right.
On Sun, 2011-11-06 at 12:23 +0200, Avi Kivity wrote:
> In most installations, qemu is driven by other programs, so any changes
> to the command line would be invisible, except insofar as they break things.
>
> For the occasional direct user of qemu, something like 'qemu-kvm -m 1G
> /images/blah.img' is enough to boot an image. This script doesn't help
> in any way.
>
> This script is for kernel developers who don't want to bother with
> setting up a disk image (which, btw, many are still required to do - I'm
> guessing most kernel developers who use qemu are cross-arch). It has
> limited scope and works mostly by hiding qemu features. As such it
> doesn't belong in qemu.
I'm certainly not against merging the script if people are actually
using it and it solves their problem.
I personally find the whole exercise pointless because it's not
attempting to solve any of the fundamental issues QEMU command line
interface has nor does it try to make Linux on Linux virtualization
simpler and more integrated.
People seem to think the KVM tool is only about solving a specific
problem to kernel developers. That's certainly never been my goal as I
do lots of userspace programming as well. The end game for me is to
replace QEMU/VirtualBox for Linux on Linux virtualization for my day to
day purposes.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 11:08 ` Pekka Enberg
@ 2011-11-06 11:50 ` Avi Kivity
2011-11-06 12:14 ` Pekka Enberg
2011-11-06 12:27 ` Pekka Enberg
0 siblings, 2 replies; 88+ messages in thread
From: Avi Kivity @ 2011-11-06 11:50 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On 11/06/2011 01:08 PM, Pekka Enberg wrote:
> On Sun, 2011-11-06 at 12:23 +0200, Avi Kivity wrote:
> > In most installations, qemu is driven by other programs, so any changes
> > to the command line would be invisible, except insofar as they break things.
> >
> > For the occasional direct user of qemu, something like 'qemu-kvm -m 1G
> > /images/blah.img' is enough to boot an image. This script doesn't help
> > in any way.
> >
> > This script is for kernel developers who don't want to bother with
> > setting up a disk image (which, btw, many are still required to do - I'm
> > guessing most kernel developers who use qemu are cross-arch). It has
> > limited scope and works mostly by hiding qemu features. As such it
> > doesn't belong in qemu.
>
> I'm certainly not against merging the script if people are actually
> using it and it solves their problem.
>
> I personally find the whole exercise pointless because it's not
> attempting to solve any of the fundamental issues QEMU command line
> interface
There are no "fundamental qemu command line issues". It's hairy, yes,
and verbose, but using "fundamental" to describe a choice between one
arcane set command line options and another is a bit of overstatement.
Most users will use a GUI anyway.
> has nor does it try to make Linux on Linux virtualization
> simpler and more integrated.
So far, kvm-tool capabilities are a subset of qemu's. Does it add
anything beyond a different command-line?
> People seem to think the KVM tool is only about solving a specific
> problem to kernel developers. That's certainly never been my goal as I
> do lots of userspace programming as well. The end game for me is to
> replace QEMU/VirtualBox for Linux on Linux virtualization for my day to
> day purposes.
Maybe it should be in tools/pekka then. Usually subsystems that want to
be merged into Linux have broaded audiences though.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 11:50 ` Avi Kivity
@ 2011-11-06 12:14 ` Pekka Enberg
2011-11-06 12:27 ` Avi Kivity
2011-11-06 12:27 ` Pekka Enberg
1 sibling, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 12:14 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity <avi@redhat.com> wrote:
>> People seem to think the KVM tool is only about solving a specific
>> problem to kernel developers. That's certainly never been my goal as I
>> do lots of userspace programming as well. The end game for me is to
>> replace QEMU/VirtualBox for Linux on Linux virtualization for my day to
>> day purposes.
>
> Maybe it should be in tools/pekka then. Usually subsystems that want to
> be merged into Linux have broaded audiences though.
I think you completely missed my point.
I'm simply saying that KVM tool was never about solving a narrow
problem Alexander's script is trying to solve. That's why I feel it's
such a pointless exercise.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 12:14 ` Pekka Enberg
@ 2011-11-06 12:27 ` Avi Kivity
2011-11-06 12:32 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Avi Kivity @ 2011-11-06 12:27 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On 11/06/2011 02:14 PM, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity <avi@redhat.com> wrote:
> >> People seem to think the KVM tool is only about solving a specific
> >> problem to kernel developers. That's certainly never been my goal as I
> >> do lots of userspace programming as well. The end game for me is to
> >> replace QEMU/VirtualBox for Linux on Linux virtualization for my day to
> >> day purposes.
> >
> > Maybe it should be in tools/pekka then. Usually subsystems that want to
> > be merged into Linux have broaded audiences though.
>
> I think you completely missed my point.
>
> I'm simply saying that KVM tool was never about solving a narrow
> problem Alexander's script is trying to solve. That's why I feel it's
> such a pointless exercise.
But from your description, you're trying to solve just another narrow
problem:
"The end game for me is to replace QEMU/VirtualBox for Linux on Linux
virtualization for my day to day purposes. "
We rarely merge a subsystem to solve one person's problem (esp. when it
is defined as "replace another freely available project", even if you
dislike its command line syntax).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 12:27 ` Avi Kivity
@ 2011-11-06 12:32 ` Pekka Enberg
2011-11-06 12:43 ` Avi Kivity
0 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 12:32 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity <avi@redhat.com> wrote:
> But from your description, you're trying to solve just another narrow
> problem:
>
> "The end game for me is to replace QEMU/VirtualBox for Linux on Linux
> virtualization for my day to day purposes. "
>
> We rarely merge a subsystem to solve one person's problem (esp. when it
> is defined as "replace another freely available project", even if you
> dislike its command line syntax).
I really don't understand your point. Other people are using the KVM
tool for other purposes. For example, the (crazy) simulation guys are
using the tool to launch even more guests on a single host and Ingo
seems to be using the tool to test kernels.
I'm not suggesting we should merge the tool because of my particular
use case. I'm simply saying the problem I personally want to solve
with the KVM tool is broader than what Alexander's script is doing.
That's why I feel it's a pointless project.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 12:32 ` Pekka Enberg
@ 2011-11-06 12:43 ` Avi Kivity
2011-11-06 13:06 ` Pekka Enberg
2011-11-06 13:11 ` Pekka Enberg
0 siblings, 2 replies; 88+ messages in thread
From: Avi Kivity @ 2011-11-06 12:43 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On 11/06/2011 02:32 PM, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity <avi@redhat.com> wrote:
> > But from your description, you're trying to solve just another narrow
> > problem:
> >
> > "The end game for me is to replace QEMU/VirtualBox for Linux on Linux
> > virtualization for my day to day purposes. "
> >
> > We rarely merge a subsystem to solve one person's problem (esp. when it
> > is defined as "replace another freely available project", even if you
> > dislike its command line syntax).
>
> I really don't understand your point. Other people are using the KVM
> tool for other purposes. For example, the (crazy) simulation guys are
> using the tool to launch even more guests on a single host and Ingo
> seems to be using the tool to test kernels.
>
> I'm not suggesting we should merge the tool because of my particular
> use case. I'm simply saying the problem I personally want to solve
> with the KVM tool is broader than what Alexander's script is doing.
> That's why I feel it's a pointless project.
We're going in circles, but I'll try again.
You say that kvm-tool's scope is broader than Alex's script, therefore
the latter is pointless.
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.
Alex's script, though, is just a few dozen lines. kvm-tool is a 20K
patch - in fact 2X as large as kvm when it was first merged. And it's
main feature seems to be that "it is not qemu".
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 12:43 ` Avi Kivity
@ 2011-11-06 13:06 ` Pekka Enberg
2011-11-06 15:56 ` Avi Kivity
` (2 more replies)
2011-11-06 13:11 ` Pekka Enberg
1 sibling, 3 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 13:06 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
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.
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
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 13:06 ` Pekka Enberg
@ 2011-11-06 15:56 ` Avi Kivity
2011-11-06 16:35 ` Pekka Enberg
2011-11-06 16:19 ` Jan Kiszka
2011-11-06 17:15 ` Alexander Graf
2 siblings, 1 reply; 88+ messages in thread
From: Avi Kivity @ 2011-11-06 15:56 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On 11/06/2011 03:06 PM, 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.
Have you tried virt-install/virt-manager?
> Alex's script is essentially just a simplified QEMU
> "front end" for kernel developers.
AFAIR it was based off a random Linus remark.
> 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.
More hackable, certainly, as any 20kloc project will be compared to a
700+kloc project with a long history. More usable, I really doubt
this. You take it for granted that people want to run their /boot
kernels in a guest, but in fact only kernel developers (and testers)
want this. The majority want the real guest kernel.
> 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).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 15:56 ` Avi Kivity
@ 2011-11-06 16:35 ` Pekka Enberg
2011-11-06 16:50 ` Avi Kivity
0 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 16:35 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
Hi Avi,
On Sun, Nov 6, 2011 at 5:56 PM, Avi Kivity <avi@redhat.com> wrote:
> On 11/06/2011 03:06 PM, 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.
>
> Have you tried virt-install/virt-manager?
No, I don't use virtio-manager. I know a lot of people do which is why
someone is working on KVM tool libvirt integration.
>> 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.
>
> More hackable, certainly, as any 20kloc project will be compared to a
> 700+kloc project with a long history. More usable, I really doubt
> this. You take it for granted that people want to run their /boot
> kernels in a guest, but in fact only kernel developers (and testers)
> want this. The majority want the real guest kernel.
Our inability to boot ISO images, for example, is a usability
limitation, sure. I'm hoping to fix that at some point.
>> 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.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 16:35 ` Pekka Enberg
@ 2011-11-06 16:50 ` Avi Kivity
0 siblings, 0 replies; 88+ messages in thread
From: Avi Kivity @ 2011-11-06 16:50 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
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.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 13:06 ` Pekka Enberg
2011-11-06 15:56 ` Avi Kivity
@ 2011-11-06 16:19 ` Jan Kiszka
2011-11-06 16:30 ` Pekka Enberg
` (2 more replies)
2011-11-06 17:15 ` Alexander Graf
2 siblings, 3 replies; 88+ messages in thread
From: Jan Kiszka @ 2011-11-06 16:19 UTC (permalink / raw)
To: Pekka Enberg
Cc: Avi Kivity, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, qemu-devel Developers,
Alexander Graf, Blue Swirl, Américo Wang, Ingo Molnar,
Linus Torvalds
[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]
On 2011-11-06 14:06, Pekka Enberg wrote:
> 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.
"Hackable" is relative. I'm surly not saying QEMU has nicer code than
kvm-tool, rather the contrary. But if it were that bad, we would not
have hundreds of contributors, just in the very recent history.
"Usable" - I've tried kvm-tool several times and still (today) fail to
get a standard SUSE image (with a kernel I have to compile and provide
separately...) up and running *). Likely a user mistake, but none that
is very obvious. At least to me.
In contrast, you can throw arbitrary Linux distros in various forms at
QEMU, and it will catch and run them. For me, already this is more usable.
Jan
*) kvm run -m 1000 -d OpenSuse11-4_64.img arch/x86/boot/bzImage \
-p root=/dev/vda2
...
[ 1.772791] mousedev: PS/2 mouse device common for all mice
[ 1.774603] cpuidle: using governor ladder
[ 1.775490] cpuidle: using governor menu
[ 1.776865] input: AT Raw Set 2 keyboard as
/devices/platform/i8042/serio0/input/input0
[ 1.778609] TCP cubic registered
[ 1.779456] Installing 9P2000 support
[ 1.782390] Registering the dns_resolver key type
[ 1.794323] registered taskstats version 1
...and here the boot just stops, guest apparently waits for something
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 16:19 ` Jan Kiszka
@ 2011-11-06 16:30 ` Pekka Enberg
2011-11-06 16:39 ` Jan Kiszka
2011-11-06 16:39 ` Pekka Enberg
2011-11-07 10:11 ` Gerd Hoffmann
2 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 16:30 UTC (permalink / raw)
To: Jan Kiszka
Cc: Avi Kivity, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, qemu-devel Developers,
Alexander Graf, Blue Swirl, Américo Wang, Ingo Molnar,
Linus Torvalds
Hi Jan,
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> "Usable" - I've tried kvm-tool several times and still (today) fail to
> get a standard SUSE image (with a kernel I have to compile and provide
> separately...) up and running *). Likely a user mistake, but none that
> is very obvious. At least to me.
>
> In contrast, you can throw arbitrary Linux distros in various forms at
> QEMU, and it will catch and run them. For me, already this is more usable.
>
> *) kvm run -m 1000 -d OpenSuse11-4_64.img arch/x86/boot/bzImage \
> -p root=/dev/vda2
> ...
> [ 1.772791] mousedev: PS/2 mouse device common for all mice
> [ 1.774603] cpuidle: using governor ladder
> [ 1.775490] cpuidle: using governor menu
> [ 1.776865] input: AT Raw Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input0
> [ 1.778609] TCP cubic registered
> [ 1.779456] Installing 9P2000 support
> [ 1.782390] Registering the dns_resolver key type
> [ 1.794323] registered taskstats version 1
>
> ...and here the boot just stops, guest apparently waits for something
Can you please share your kernel .config with me and I'll take a look
at it. We now have a "make kvmconfig" makefile target for enabling all
the necessary config options for guest kernels. I don't think any of
us developers are using SUSE so it can surely be a KVM tool bug as
well.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 16:30 ` Pekka Enberg
@ 2011-11-06 16:39 ` Jan Kiszka
2011-11-06 17:11 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Jan Kiszka @ 2011-11-06 16:39 UTC (permalink / raw)
To: Pekka Enberg
Cc: Avi Kivity, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, qemu-devel Developers,
Alexander Graf, Blue Swirl, Américo Wang, Ingo Molnar,
Linus Torvalds
[-- Attachment #1.1: Type: text/plain, Size: 1517 bytes --]
On 2011-11-06 17:30, Pekka Enberg wrote:
> Hi Jan,
>
> On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> "Usable" - I've tried kvm-tool several times and still (today) fail to
>> get a standard SUSE image (with a kernel I have to compile and provide
>> separately...) up and running *). Likely a user mistake, but none that
>> is very obvious. At least to me.
>>
>> In contrast, you can throw arbitrary Linux distros in various forms at
>> QEMU, and it will catch and run them. For me, already this is more usable.
>>
>> *) kvm run -m 1000 -d OpenSuse11-4_64.img arch/x86/boot/bzImage \
>> -p root=/dev/vda2
>> ...
>> [ 1.772791] mousedev: PS/2 mouse device common for all mice
>> [ 1.774603] cpuidle: using governor ladder
>> [ 1.775490] cpuidle: using governor menu
>> [ 1.776865] input: AT Raw Set 2 keyboard as
>> /devices/platform/i8042/serio0/input/input0
>> [ 1.778609] TCP cubic registered
>> [ 1.779456] Installing 9P2000 support
>> [ 1.782390] Registering the dns_resolver key type
>> [ 1.794323] registered taskstats version 1
>>
>> ...and here the boot just stops, guest apparently waits for something
>
> Can you please share your kernel .config with me and I'll take a look
> at it. We now have a "make kvmconfig" makefile target for enabling all
> the necessary config options for guest kernels. I don't think any of
> us developers are using SUSE so it can surely be a KVM tool bug as
> well.
Attached.
Jan
[-- Attachment #1.2: .config.bz2 --]
[-- Type: application/x-bzip, Size: 18766 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 16:39 ` Jan Kiszka
@ 2011-11-06 17:11 ` Pekka Enberg
2011-11-06 17:23 ` Jan Kiszka
0 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 17:11 UTC (permalink / raw)
To: Jan Kiszka
Cc: Pekka Enberg, Avi Kivity, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, qemu-devel Developers,
Alexander Graf, Blue Swirl, Américo Wang, Ingo Molnar,
Linus Torvalds
On Sun, 6 Nov 2011, Jan Kiszka wrote:
>> Can you please share your kernel .config with me and I'll take a look
>> at it. We now have a "make kvmconfig" makefile target for enabling all
>> the necessary config options for guest kernels. I don't think any of
>> us developers are using SUSE so it can surely be a KVM tool bug as
>> well.
>
> Attached.
It hang here as well. I ran
make kvmconfig
on your .config and it works. It's basically these two:
@@ -1478,7 +1478,7 @@
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
-CONFIG_VIRTIO_NET=m
+CONFIG_VIRTIO_NET=y
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
@@ -1690,7 +1690,7 @@
# CONFIG_SERIAL_PCH_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
CONFIG_HVC_DRIVER=y
-CONFIG_VIRTIO_CONSOLE=m
+CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 17:11 ` Pekka Enberg
@ 2011-11-06 17:23 ` Jan Kiszka
2011-11-06 17:55 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Jan Kiszka @ 2011-11-06 17:23 UTC (permalink / raw)
To: Pekka Enberg
Cc: Pekka Enberg, Avi Kivity, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, qemu-devel Developers,
Alexander Graf, Blue Swirl, Américo Wang, Ingo Molnar,
Linus Torvalds
[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]
On 2011-11-06 18:11, Pekka Enberg wrote:
> On Sun, 6 Nov 2011, Jan Kiszka wrote:
>>> Can you please share your kernel .config with me and I'll take a look
>>> at it. We now have a "make kvmconfig" makefile target for enabling all
>>> the necessary config options for guest kernels. I don't think any of
>>> us developers are using SUSE so it can surely be a KVM tool bug as
>>> well.
>>
>> Attached.
>
> It hang here as well. I ran
>
> make kvmconfig
>
> on your .config and it works. It's basically these two:
>
> @@ -1478,7 +1478,7 @@
> CONFIG_NETPOLL=y
> # CONFIG_NETPOLL_TRAP is not set
> CONFIG_NET_POLL_CONTROLLER=y
> -CONFIG_VIRTIO_NET=m
> +CONFIG_VIRTIO_NET=y
> # CONFIG_VMXNET3 is not set
> # CONFIG_ISDN is not set
> # CONFIG_PHONE is not set
> @@ -1690,7 +1690,7 @@
> # CONFIG_SERIAL_PCH_UART is not set
> # CONFIG_SERIAL_XILINX_PS_UART is not set
> CONFIG_HVC_DRIVER=y
> -CONFIG_VIRTIO_CONSOLE=m
> +CONFIG_VIRTIO_CONSOLE=y
> CONFIG_IPMI_HANDLER=m
> # CONFIG_IPMI_PANIC_EVENT is not set
> CONFIG_IPMI_DEVICE_INTERFACE=m
>
> Pekka
Doesn't help here (with a disk image).
Also, both dependencies make no sense to me as we boot from disk, not
from net, and the console is on ttyS0.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 17:23 ` Jan Kiszka
@ 2011-11-06 17:55 ` Pekka Enberg
0 siblings, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 17:55 UTC (permalink / raw)
To: Jan Kiszka
Cc: Pekka Enberg, Avi Kivity, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, qemu-devel Developers,
Alexander Graf, Blue Swirl, Américo Wang, Ingo Molnar,
Linus Torvalds, Sasha Levin, Asias He
On Sun, 6 Nov 2011, Jan Kiszka wrote:
> Doesn't help here (with a disk image).
>
> Also, both dependencies make no sense to me as we boot from disk, not
> from net, and the console is on ttyS0.
It's only VIRTIO_NET and the guest is not actually stuck, it just takes a
while to boot:
[ 1.866614] Installing 9P2000 support
[ 1.868991] Registering the dns_resolver key type
[ 1.878084] registered taskstats version 1
[ 13.927367] Root-NFS: no NFS server address
[ 13.929500] VFS: Unable to mount root fs via NFS, trying floppy.
[ 13.939177] VFS: Mounted root (9p filesystem) on device 0:12.
[ 13.941522] devtmpfs: mounted
[ 13.943317] Freeing unused kernel memory: 684k freed
Mounting...
Starting '/bin/sh'...
sh-4.2#
I'm CC'ing Sasha and Asias.
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 16:19 ` Jan Kiszka
2011-11-06 16:30 ` Pekka Enberg
@ 2011-11-06 16:39 ` Pekka Enberg
2011-11-07 10:11 ` Gerd Hoffmann
2 siblings, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 16:39 UTC (permalink / raw)
To: Jan Kiszka
Cc: Avi Kivity, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, qemu-devel Developers,
Alexander Graf, Blue Swirl, Américo Wang, Ingo Molnar,
Linus Torvalds
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> In contrast, you can throw arbitrary Linux distros in various forms at
> QEMU, and it will catch and run them. For me, already this is more usable.
Yes, I completely agree that this is an unfortunate limitation in the
KVM tool. We definitely need to support booting to images which have
virtio drivers enabled.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 16:19 ` Jan Kiszka
2011-11-06 16:30 ` Pekka Enberg
2011-11-06 16:39 ` Pekka Enberg
@ 2011-11-07 10:11 ` Gerd Hoffmann
2011-11-07 10:18 ` Pekka Enberg
2 siblings, 1 reply; 88+ messages in thread
From: Gerd Hoffmann @ 2011-11-07 10:11 UTC (permalink / raw)
To: Jan Kiszka
Cc: Pekka Enberg, Avi Kivity, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, qemu-devel Developers,
Alexander Graf, Blue Swirl, Américo Wang, Ingo Molnar,
Linus Torvalds
Hi,
> "Usable" - I've tried kvm-tool several times and still (today) fail to
> get a standard SUSE image (with a kernel I have to compile and provide
> separately...) up and running *). Likely a user mistake, but none that
> is very obvious. At least to me.
Same here.
No support for booting from CDROM.
No support for booting from Network.
Thus no way to install a new guest image.
Booting an existing qcow2 guest image failed, the guest started throwing
I/O errors. And even to try that I had to manually extract the kernel
and initrd images from the guest. Maybe you should check with the Xen
guys, they have a funky 'pygrub' which sort-of automates the
copy-kernel-from-guest-image process.
Booting the host kernel failed too. Standard distro kernel. The virtio
bits are modular, not statically compiled into the kernel. kvm tool
can't handle that.
You have to build your own kernel and make sure you flip the correct
config bits, then you can boot it to a shell prompt. Trying anything
else just doesn't work today ...
cheers,
Gerd
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 10:11 ` Gerd Hoffmann
@ 2011-11-07 10:18 ` Pekka Enberg
0 siblings, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 10:18 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Jan Kiszka, Avi Kivity, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, qemu-devel Developers,
Alexander Graf, Blue Swirl, Américo Wang, Ingo Molnar,
Linus Torvalds
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> No support for booting from CDROM.
> No support for booting from Network.
> Thus no way to install a new guest image.
Sure. It's a pain point which we need to fix.
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> Booting an existing qcow2 guest image failed, the guest started throwing
> I/O errors. And even to try that I had to manually extract the kernel
> and initrd images from the guest. Maybe you should check with the Xen
> guys, they have a funky 'pygrub' which sort-of automates the
> copy-kernel-from-guest-image process.
QCOW2 support is experimental. The I/O errors are caused by forced
read-only mode.
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> Booting the host kernel failed too. Standard distro kernel. The virtio
> bits are modular, not statically compiled into the kernel. kvm tool
> can't handle that.
I think we have some support for booting modular distro kernels too if
you tell KVM tool where to find initrd. It sucks out-of-the-box though
because nobody seems to be using it.
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> You have to build your own kernel and make sure you flip the correct
> config bits, then you can boot it to a shell prompt. Trying anything
> else just doesn't work today ...
What can I say? Patches welcome? :-)
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 13:06 ` Pekka Enberg
2011-11-06 15:56 ` Avi Kivity
2011-11-06 16:19 ` Jan Kiszka
@ 2011-11-06 17:15 ` Alexander Graf
2011-11-06 17:28 ` Pekka Enberg
2 siblings, 1 reply; 88+ messages in thread
From: Alexander Graf @ 2011-11-06 17:15 UTC (permalink / raw)
To: Pekka Enberg
Cc: Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On 06.11.2011, at 05:06, 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.
It's a script tailored to what Linus told me he wanted to see. I merely wanted to prove the point that what he wanted can be achieved without thousands and thousands of lines of code by reusing what is already there. IMHO less code is usually a good thing.
In fact, why don't you just provide a script in tools/testing/ that fetches KVM Tool from a git tree somewhere else and compiles it? It could easily live outside the kernel tree - you can even grab our awesome "fetch all Linux headers" script from QEMU so you can keep in sync with KVM header files.
At that point, both front ends would live in separate trees, could evolve however they like and everyone's happy, because KVM Tools would still be easy to use for people who want it by executing said shell script.
>
> 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.
Sure. That's taste. If I think that tcsh is a better shell than bash do I pull it into the kernel tree just so "it lies there"? It definitely does use kernel interfaces too, so I can make up just as many reasons as you to pull it in.
> 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.
It's a matter of size and scope. Write a shell script that clones, builds and executes KVM Tool and throw it in testing/tools/ and I'll happily ack it!
Alex
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 17:15 ` Alexander Graf
@ 2011-11-06 17:28 ` Pekka Enberg
2011-11-06 17:30 ` Alexander Graf
` (2 more replies)
0 siblings, 3 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 17:28 UTC (permalink / raw)
To: Alexander Graf
Cc: Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf <agraf@suse.de> 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.
>
> It's a matter of size and scope. Write a shell script that clones, builds and
> executes KVM Tool and throw it in testing/tools/ and I'll happily ack it!
That's pretty much what git submodule would do, isn't it?
I really don't see the point in doing that. We want to be part of
regular kernel history and release cycle. We want people to be able to
see what's going on in our tree to keep us honest and we want to make
the barrier of entry as low as possible.
It's not just about code, it's as much about culture and development process.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 17:28 ` Pekka Enberg
@ 2011-11-06 17:30 ` Alexander Graf
2011-11-06 18:05 ` Pekka Enberg
2011-11-06 22:08 ` Frank Ch. Eigler
2011-11-06 19:11 ` Paolo Bonzini
2011-11-07 10:23 ` Gerd Hoffmann
2 siblings, 2 replies; 88+ messages in thread
From: Alexander Graf @ 2011-11-06 17:30 UTC (permalink / raw)
To: Pekka Enberg
Cc: Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On 06.11.2011, at 09:28, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf <agraf@suse.de> 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.
>>
>> It's a matter of size and scope. Write a shell script that clones, builds and
>> executes KVM Tool and throw it in testing/tools/ and I'll happily ack it!
>
> That's pretty much what git submodule would do, isn't it?
>
> I really don't see the point in doing that. We want to be part of
> regular kernel history and release cycle. We want people to be able to
> see what's going on in our tree to keep us honest and we want to make
> the barrier of entry as low as possible.
>
> It's not just about code, it's as much about culture and development process.
So you're saying that projects that are not living in the kernel tree aren't worthwhile? Or are you only trying to bump your oloh stats?
I mean, seriously, git makes it so easy to have a separate tree that it almost doesn't make sense not to have one. You're constantly working in separate trees yourself because every one of your branches is separate. Keeping in sync with the kernel release cycles (which I don't think makes any sense for you) should be easy enough too by merely releasing in sync with the kernel tree...
Alex
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 17:30 ` Alexander Graf
@ 2011-11-06 18:05 ` Pekka Enberg
2011-11-06 19:14 ` Paolo Bonzini
2011-11-06 22:08 ` Frank Ch. Eigler
1 sibling, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 18:05 UTC (permalink / raw)
To: Alexander Graf
Cc: Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On Sun, Nov 6, 2011 at 7:30 PM, Alexander Graf <agraf@suse.de> wrote:
>> That's pretty much what git submodule would do, isn't it?
>>
>> I really don't see the point in doing that. We want to be part of
>> regular kernel history and release cycle. We want people to be able to
>> see what's going on in our tree to keep us honest and we want to make
>> the barrier of entry as low as possible.
>>
>> It's not just about code, it's as much about culture and development process.
>
> So you're saying that projects that are not living in the kernel tree aren't worthwhile?
Yeah, that's exactly what I'm saying...
> Or are you only trying to bump your oloh stats?
That too!
On Sun, Nov 6, 2011 at 7:30 PM, Alexander Graf <agraf@suse.de> wrote:
> I mean, seriously, git makes it so easy to have a separate tree that
> it almost doesn't make sense not to have one. You're constantly
> working in separate trees yourself because every one of your
> branches is separate. Keeping in sync with the kernel release cycles
> (which I don't think makes any sense for you) should be easy enough
> too by merely releasing in sync with the kernel tree...
We'd be the only subsystem doing that! Why on earth do you think we
want to be the first ones to do that? We don't want to be different,
we want to make the barrier of entry low.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 18:05 ` Pekka Enberg
@ 2011-11-06 19:14 ` Paolo Bonzini
2011-11-06 19:19 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Paolo Bonzini @ 2011-11-06 19:14 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On 11/06/2011 07:05 PM, Pekka Enberg wrote:
>> I mean, seriously, git makes it so easy to have a separate tree that
>> > it almost doesn't make sense not to have one. You're constantly
>> > working in separate trees yourself because every one of your
>> > branches is separate. Keeping in sync with the kernel release cycles
>> > (which I don't think makes any sense for you) should be easy enough
>> > too by merely releasing in sync with the kernel tree...
> We'd be the only subsystem doing that!
GStreamer (V4L), RTSAdmin (LIO target), sg3_utils, trousers all are out
of tree, and nobody of their authors is even thinking of doing all this
brouhaha to get merged into Linus's tree.
Paolo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 19:14 ` Paolo Bonzini
@ 2011-11-06 19:19 ` Pekka Enberg
0 siblings, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 19:19 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On Sun, Nov 6, 2011 at 9:14 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> GStreamer (V4L), RTSAdmin (LIO target), sg3_utils, trousers all are out of
> tree, and nobody of their authors is even thinking of doing all this
> brouhaha to get merged into Linus's tree.
We'd be the first subsystem to use the download script thing Alex suggested.
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 17:30 ` Alexander Graf
2011-11-06 18:05 ` Pekka Enberg
@ 2011-11-06 22:08 ` Frank Ch. Eigler
2011-11-07 6:58 ` Pekka Enberg
1 sibling, 1 reply; 88+ messages in thread
From: Frank Ch. Eigler @ 2011-11-06 22:08 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
=?ISO-8859-1?Q?Am=E9rico_Wang?=, Ingo Molnar, Linus Torvalds
$ <CAOJsxLFCjkAK7Lw4M15G44k11zrcF7tnu9yMbiQYDBNZr+83tg@mail.gmail.com>
From: fche@redhat.com (Frank Ch. Eigler)
Date: Sun, 06 Nov 2011 17:08:48 -0500
In-Reply-To: <CAOJsxLFCjkAK7Lw4M15G44k11zrcF7tnu9yMbiQYDBNZr+83tg@mail.gmail.com> (Pekka Enberg's message of "Sun, 6 Nov 2011 20:05:45 +0200")
Message-ID: <y0mhb2g6gzz.fsf@fche.csb>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Pekka Enberg <penberg@kernel.org> writes:
> [...] We don't want to be different, we want to make the barrier of
> entry low.
When has the barrier of entry into the kernel ever been "low"
for anyone not already working in the kernel?
- FChE
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 22:08 ` Frank Ch. Eigler
@ 2011-11-07 6:58 ` Pekka Enberg
0 siblings, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 6:58 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On Mon, Nov 7, 2011 at 12:08 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
>> [...] We don't want to be different, we want to make the barrier of
>> entry low.
>
> When has the barrier of entry into the kernel ever been "low"
> for anyone not already working in the kernel?
What's your point? Working on the KVM tool requires knowledge of the
Linux kernel.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 17:28 ` Pekka Enberg
2011-11-06 17:30 ` Alexander Graf
@ 2011-11-06 19:11 ` Paolo Bonzini
2011-11-06 19:17 ` Pekka Enberg
2011-11-07 10:23 ` Gerd Hoffmann
2 siblings, 1 reply; 88+ messages in thread
From: Paolo Bonzini @ 2011-11-06 19:11 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On 11/06/2011 06:28 PM, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf<agraf@suse.de> 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.
>>
>> It's a matter of size and scope. Write a shell script that clones, builds and
>> executes KVM Tool and throw it in testing/tools/ and I'll happily ack it!
>
> That's pretty much what git submodule would do, isn't it?
Absolutely not. It would always fetch HEAD from the KVM tool repo. A
submodule ties each supermodule commit to a particular submodule commit.
> I really don't see the point in doing that. We want to be part of
> regular kernel history and release cycle.
But I'm pretty certain that, when testing 3.2 with KVM tool in a couple
of years, I want all the shining new features you added in this time; I
don't want the old end-2011 code. Same if I'm bisecting kernels, I
don't want to build KVM tool once per bisection cycle, do I?
Paolo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 19:11 ` Paolo Bonzini
@ 2011-11-06 19:17 ` Pekka Enberg
2011-11-06 20:01 ` Paolo Bonzini
0 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 19:17 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On Sun, Nov 6, 2011 at 9:11 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> I really don't see the point in doing that. We want to be part of
>> regular kernel history and release cycle.
>
> But I'm pretty certain that, when testing 3.2 with KVM tool in a couple of
> years, I want all the shining new features you added in this time; I don't
> want the old end-2011 code. Same if I'm bisecting kernels, I don't want to
> build KVM tool once per bisection cycle, do I?
If you're bisecting breakage that can be in the guest kernel or the
KVM tool, you'd want to build both.
What would prevent you from using a newer KVM tool with an older kernel?
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 19:17 ` Pekka Enberg
@ 2011-11-06 20:01 ` Paolo Bonzini
2011-11-06 20:17 ` Pekka Enberg
2011-11-06 20:31 ` Pekka Enberg
0 siblings, 2 replies; 88+ messages in thread
From: Paolo Bonzini @ 2011-11-06 20:01 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On 11/06/2011 08:17 PM, Pekka Enberg wrote:
>> > But I'm pretty certain that, when testing 3.2 with KVM tool in a couple of
>> > years, I want all the shining new features you added in this time; I don't
>> > want the old end-2011 code. Same if I'm bisecting kernels, I don't want to
>> > build KVM tool once per bisection cycle, do I?
>
> If you're bisecting breakage that can be in the guest kernel or the
> KVM tool, you'd want to build both.
No. I want to try new tool/old kernel and old tool/new kernel (kernel
can be either guest or host, depending on the nature of the bug), and
then bisect just one. (*) And that's the exceptional case, and only KVM
tool developers really should have the need to do that.
(*) Not coincidentially, that's what git bisect does when HEAD is
a merge of two unrelated histories.
> What would prevent you from using a newer KVM tool with an older kernel?
Nothing, but I'm just giving you *strong* hints that a submodule or a
merged tool is the wrong solution, and the histories of kernel and tool
should be kept separate.
More clearly: for its supposedly intended usage, namely testing
development kernels in a *guest*, KVM tool will generally not run on the
exact *host* kernel that is in the tree it lives with. Almost never, in
fact. Unlike perf, if you want to test multiple guest kernels you
should never need to rebuild KVM tool!
This is the main argument as to whether or not to merge the tool. Would
the integration of the *build* make sense or not? Assume you adapt the
ktest script to make both the KVM tool and the kernel, and test the
latter using the former. Your host kernel never changes, and yet you
introduce a new variable in your testing. That complicates things, it
doesn't simplify them.
Paolo
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 20:01 ` Paolo Bonzini
@ 2011-11-06 20:17 ` Pekka Enberg
2011-11-07 8:00 ` Paolo Bonzini
2011-11-06 20:31 ` Pekka Enberg
1 sibling, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 20:17 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> If you're bisecting breakage that can be in the guest kernel or the
>> KVM tool, you'd want to build both.
>
> No. I want to try new tool/old kernel and old tool/new kernel (kernel can
> be either guest or host, depending on the nature of the bug), and then
> bisect just one. (*) And that's the exceptional case, and only KVM tool
> developers really should have the need to do that.
Exactly - having the source code in Linux kernel tree covers the
"exceptional case" where we're unsure which part of the equation broke
things (which are btw the nasties issues we've had so far). I have no
idea why you're trying to convince me that it doesn't matter. You can
bisect only one of the components in isolation just fine.
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> What would prevent you from using a newer KVM tool with an older kernel?
>
> Nothing, but I'm just giving you *strong* hints that a submodule or a merged
> tool is the wrong solution, and the histories of kernel and tool should be
> kept separate.
>
> More clearly: for its supposedly intended usage, namely testing development
> kernels in a *guest*, KVM tool will generally not run on the exact *host*
> kernel that is in the tree it lives with. Almost never, in fact. Unlike
> perf, if you want to test multiple guest kernels you should never need to
> rebuild KVM tool!
>
> This is the main argument as to whether or not to merge the tool. Would the
> integration of the *build* make sense or not? Assume you adapt the ktest
> script to make both the KVM tool and the kernel, and test the latter using
> the former. Your host kernel never changes, and yet you introduce a new
> variable in your testing. That complicates things, it doesn't simplify
> them.
I don't understand what trying to say. There's no requirement to build
the KVM tool if you're bisecting a guest kernel.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 20:17 ` Pekka Enberg
@ 2011-11-07 8:00 ` Paolo Bonzini
2011-11-07 8:09 ` Pekka Enberg
2011-11-07 8:13 ` Pekka Enberg
0 siblings, 2 replies; 88+ messages in thread
From: Paolo Bonzini @ 2011-11-07 8:00 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On 11/06/2011 09:17 PM, Pekka Enberg wrote:
> > No. I want to try new tool/old kernel and old tool/new kernel (kernel can
> > be either guest or host, depending on the nature of the bug), and then
> > bisect just one. (*) And that's the exceptional case, and only KVM tool
> > developers really should have the need to do that.
>
> Exactly - having the source code in Linux kernel tree covers the
> "exceptional case" where we're unsure which part of the equation broke
> things (which are btw the nasties issues we've had so far).
No, having the source code in Linux kernel tree is perfectly useless for
the exceptional case, and forces you to go through extra hoops to build
only one component. Small hoops such as adding "-- tools/kvm" to "git
bisect start" perhaps, but still hoops that aren't traded for a
practical advantage. You keep saying "oh things have been so much
better" because "it's so close to the kernel" and "it worked so great
for perf", but you haven't brought any practical example that we can
stare at in admiration.
(BTW, I'm also convinced like Ted that not having a defined perf ABI
might have made sense in the beginning, but it has now devolved into bad
software engineering practice).
> I have no idea why you're trying to convince me that it doesn't matter.
I'm not trying to convince you that it doesn't matter, I'm trying to
convince you that it doesn't *make sense*.
> It's a hypervisor that implements virtio drivers, serial
> emulation, and mini-BIOS.
... all of which have a spec against which you should be working. Save
perhaps for the mini-BIOS, if you develop against the kernel source
rather than the spec you're doing it *wrong*. Very wrong. But you've
been told this many times already.
Paolo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 8:00 ` Paolo Bonzini
@ 2011-11-07 8:09 ` Pekka Enberg
2011-11-07 8:20 ` Paolo Bonzini
2011-11-07 8:13 ` Pekka Enberg
1 sibling, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 8:09 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> No, having the source code in Linux kernel tree is perfectly useless for the
> exceptional case, and forces you to go through extra hoops to build only one
> component. Small hoops such as adding "-- tools/kvm" to "git bisect start"
> perhaps, but still hoops that aren't traded for a practical advantage. You
> keep saying "oh things have been so much better" because "it's so close to
> the kernel" and "it worked so great for perf", but you haven't brought any
> practical example that we can stare at in admiration.
The _practical example_ is the working software in tools/kvm!
>> I have no idea why you're trying to convince me that it doesn't matter.
>
> I'm not trying to convince you that it doesn't matter, I'm trying to
> convince you that it doesn't *make sense*.
>
>> It's a hypervisor that implements virtio drivers, serial
>> emulation, and mini-BIOS.
>
> ... all of which have a spec against which you should be working. Save
> perhaps for the mini-BIOS, if you develop against the kernel source rather
> than the spec you're doing it *wrong*. Very wrong. But you've been told
> this many times already.
I have zero interest in arguing with you about something you have no
practical experience on. I've tried both out-of-tree and in-tree
development for the KVM tool and I can tell you the latter is much
more productive environment.
We are obviously also using specifications but as you damn well should
know, specifications don't matter nearly as much as working code.
That's why it's important to have easy access to both.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 8:09 ` Pekka Enberg
@ 2011-11-07 8:20 ` Paolo Bonzini
2011-11-07 8:45 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Paolo Bonzini @ 2011-11-07 8:20 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On 11/07/2011 09:09 AM, Pekka Enberg wrote:
> We are obviously also using specifications but as you damn well should
> know, specifications don't matter nearly as much as working code.
Specifications matter much more than working code. Quirks are a fact of
life but should always come second.
To bring you an example from the kernel, there is a very boring list of
"PCI quirks" and a lot of code for "PCI specs", not the other way round.
Paolo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 8:20 ` Paolo Bonzini
@ 2011-11-07 8:45 ` Pekka Enberg
2011-11-07 8:52 ` Paolo Bonzini
0 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 8:45 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Pekka Enberg, Alexander Graf, kvm@vger.kernel.org list,
qemu-devel Developers, linux-kernel@vger.kernel.org List,
Blue Swirl, Avi Kivity, Américo Wang, Ingo Molnar,
Linus Torvalds
[-- Attachment #1: Type: TEXT/PLAIN, Size: 661 bytes --]
On 11/07/2011 09:09 AM, Pekka Enberg wrote:
>> We are obviously also using specifications but as you damn well should
>> know, specifications don't matter nearly as much as working code.
On Mon, 7 Nov 2011, Paolo Bonzini wrote:
> Specifications matter much more than working code. Quirks are a fact of life
> but should always come second.
To quote Linus:
And I have seen _lots_ of total crap work that was based on specs. It's
_the_ single worst way to write software, because it by definition means
that the software was written to match theory, not reality.
[ http://kerneltrap.org/node/5725 ]
So no, I don't agree with you at all.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 8:45 ` Pekka Enberg
@ 2011-11-07 8:52 ` Paolo Bonzini
2011-11-07 8:57 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Paolo Bonzini @ 2011-11-07 8:52 UTC (permalink / raw)
To: Pekka Enberg
Cc: Pekka Enberg, Alexander Graf, kvm@vger.kernel.org list,
qemu-devel Developers, linux-kernel@vger.kernel.org List,
Blue Swirl, Avi Kivity, Américo Wang, Ingo Molnar,
Linus Torvalds
On 11/07/2011 09:45 AM, Pekka Enberg wrote:
>
>> Specifications matter much more than working code. Quirks are a fact
>> of life but should always come second.
>
> To quote Linus:
>
> And I have seen _lots_ of total crap work that was based on specs. It's
> _the_ single worst way to write software, because it by definition means
> that the software was written to match theory, not reality.
All generalizations are false.
Paolo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 8:52 ` Paolo Bonzini
@ 2011-11-07 8:57 ` Pekka Enberg
0 siblings, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 8:57 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On 11/07/2011 09:45 AM, Pekka Enberg wrote:
>>> Specifications matter much more than working code. Quirks are a fact
>>> of life but should always come second.
>>
>> To quote Linus:
>>
>> And I have seen _lots_ of total crap work that was based on specs. It's
>> _the_ single worst way to write software, because it by definition means
>> that the software was written to match theory, not reality.
On Mon, Nov 7, 2011 at 10:52 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> All generalizations are false.
What is that supposed to mean? You claimed we're "doing it wrong" and
I explained you why we are doing it the way we are.
Really, the way we do things in the KVM tool is not a bug, it's a feature.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 8:00 ` Paolo Bonzini
2011-11-07 8:09 ` Pekka Enberg
@ 2011-11-07 8:13 ` Pekka Enberg
1 sibling, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 8:13 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> (BTW, I'm also convinced like Ted that not having a defined perf ABI might
> have made sense in the beginning, but it has now devolved into bad software
> engineering practice).
I'm not a perf maintainer so I don't know what the situation with wrt.
ABI breakage is. Your or Ted's comments don't match my assumptions or
experience, though.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 20:01 ` Paolo Bonzini
2011-11-06 20:17 ` Pekka Enberg
@ 2011-11-06 20:31 ` Pekka Enberg
1 sibling, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 20:31 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Nothing, but I'm just giving you *strong* hints that a submodule or a merged
> tool is the wrong solution, and the histories of kernel and tool should be
> kept separate.
And btw, I don't really understand what you're trying to accomplish
with this line of reasoning. We've tried both separate and shared
repository and the latter is much better from development point of
view.
This is not some random userspace project that uses the kernel system
calls. It's a hypervisor that implements virtio drivers, serial
emulation, and mini-BIOS. It's very close to the kernel which is why
it's such a good fit with the kernel tree.
I'd actually be willing to argue that from purely technical point of
view, KVM tool makes much more sense to have in the kernel tree than
perf does.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 17:28 ` Pekka Enberg
2011-11-06 17:30 ` Alexander Graf
2011-11-06 19:11 ` Paolo Bonzini
@ 2011-11-07 10:23 ` Gerd Hoffmann
2011-11-07 10:30 ` [Qemu-devel] " Sasha Levin
2011-11-07 11:34 ` Pekka Enberg
2 siblings, 2 replies; 88+ messages in thread
From: Gerd Hoffmann @ 2011-11-07 10:23 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
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.
cheers,
Gerd
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 10:23 ` Gerd Hoffmann
@ 2011-11-07 10:30 ` Sasha Levin
2011-11-07 11:02 ` Paolo Bonzini
2011-11-07 11:34 ` Pekka Enberg
1 sibling, 1 reply; 88+ messages in thread
From: Sasha Levin @ 2011-11-07 10:30 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Pekka Enberg, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Alexander Graf, Blue Swirl,
Avi Kivity, Américo Wang, Ingo Molnar, Linus Torvalds
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?
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 10:30 ` [Qemu-devel] " Sasha Levin
@ 2011-11-07 11:02 ` Paolo Bonzini
2011-11-07 11:44 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Paolo Bonzini @ 2011-11-07 11:02 UTC (permalink / raw)
To: Sasha Levin
Cc: Gerd Hoffmann, Blue Swirl, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, Alexander Graf,
qemu-devel Developers, Pekka Enberg, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
On 11/07/2011 11:30 AM, Sasha Levin wrote:
> > 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?
Indeed I do not see any advantage, since all the interfaces they use are
stable anyway (sysfs, msr.ko).
If they had gone in x86info, for example, my distro (F16, not exactly
conservative) would have likely picked those tools up already, but it
didn't.
Paolo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 11:02 ` Paolo Bonzini
@ 2011-11-07 11:44 ` Pekka Enberg
2011-11-07 12:18 ` Gerd Hoffmann
0 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 11:44 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Sasha Levin, Gerd Hoffmann, Blue Swirl, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, Alexander Graf,
qemu-devel Developers, Avi Kivity, Américo Wang, Ingo Molnar,
Linus Torvalds
On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Indeed I do not see any advantage, since all the interfaces they use are
> stable anyway (sysfs, msr.ko).
>
> If they had gone in x86info, for example, my distro (F16, not exactly
> conservative) would have likely picked those tools up already, but it
> didn't.
Distributing userspace tools in the kernel tree is a relatively new
concept so it's not at all surprising distributions don't pick them up
as quickly. That doesn't mean it's a fundamentally flawed approach,
though.
Also, I'm mostly interested in defending the KVM tool, so I'd prefer
not to argue whether or not carrying userspace code in the kernel tree
makes sense or not. The fact is that Linux is already doing it and I
think the only relevant question is whether or not the KVM tool
qualifies. I obviously think the answer is yes.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 11:44 ` Pekka Enberg
@ 2011-11-07 12:18 ` Gerd Hoffmann
2011-11-07 12:21 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Gerd Hoffmann @ 2011-11-07 12:18 UTC (permalink / raw)
To: Pekka Enberg
Cc: Paolo Bonzini, Sasha Levin, Blue Swirl, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, Alexander Graf,
qemu-devel Developers, Avi Kivity, Américo Wang, Ingo Molnar,
Linus Torvalds
On 11/07/11 12:44, Pekka Enberg wrote:
> On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Indeed I do not see any advantage, since all the interfaces they use are
>> stable anyway (sysfs, msr.ko).
>>
>> If they had gone in x86info, for example, my distro (F16, not exactly
>> conservative) would have likely picked those tools up already, but it
>> didn't.
>
> Distributing userspace tools in the kernel tree is a relatively new
> concept so it's not at all surprising distributions don't pick them up
> as quickly. That doesn't mean it's a fundamentally flawed approach,
> though.
tools/ lacks a separation into "kernel hacker's testing+debugging
toolbox" and "userspace tools". It lacks proper buildsystem integration
for the userspace tools, there is no "make tools" and also no "make
tools_install". Silently dropping new stuff into tools/ and expecting
the world magically noticing isn't going to work.
cheers,
Gerd
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 12:18 ` Gerd Hoffmann
@ 2011-11-07 12:21 ` Pekka Enberg
0 siblings, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 12:21 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Paolo Bonzini, Sasha Levin, Blue Swirl, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, Alexander Graf,
qemu-devel Developers, Avi Kivity, Américo Wang, Ingo Molnar,
Linus Torvalds
On Mon, Nov 7, 2011 at 2:18 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> tools/ lacks a separation into "kernel hacker's testing+debugging
> toolbox" and "userspace tools". It lacks proper buildsystem integration
> for the userspace tools, there is no "make tools" and also no "make
> tools_install". Silently dropping new stuff into tools/ and expecting
> the world magically noticing isn't going to work.
No disagreement here.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 10:23 ` Gerd Hoffmann
2011-11-07 10:30 ` [Qemu-devel] " Sasha Levin
@ 2011-11-07 11:34 ` Pekka Enberg
2011-11-07 11:57 ` Ingo Molnar
2011-11-07 12:08 ` Gerd Hoffmann
1 sibling, 2 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 11:34 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Pekka Enberg, Alexander Graf, Avi Kivity, Linus Torvalds,
Ingo Molnar, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers,
Américo Wang, Blue Swirl
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.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 11:34 ` Pekka Enberg
@ 2011-11-07 11:57 ` Ingo Molnar
2011-11-07 12:08 ` Gerd Hoffmann
1 sibling, 0 replies; 88+ messages in thread
From: Ingo Molnar @ 2011-11-07 11:57 UTC (permalink / raw)
To: Pekka Enberg
Cc: Gerd Hoffmann, Pekka Enberg, Alexander Graf, Avi Kivity,
Linus Torvalds, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers,
Américo Wang, Blue Swirl
* 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."
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.
The only valid technical objection against tools/kvm/ that i can see
would be that it's not useful enough yet for the upstream kernel
versus other tools such as Qemu. In all fairness i think we might
still be at that early stage of the project but it's clearly
progressing very rapidly and i'm already using it on a daily basis
for my own kernel testing purposes. During the Kernel Summit that's
how i tested contemporary kernels on contemporary user-space
remotely, without having to risk a physical reboot.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 11:34 ` Pekka Enberg
2011-11-07 11:57 ` Ingo Molnar
@ 2011-11-07 12:08 ` Gerd Hoffmann
2011-11-07 12:29 ` Ted Ts'o
1 sibling, 1 reply; 88+ messages in thread
From: Gerd Hoffmann @ 2011-11-07 12:08 UTC (permalink / raw)
To: Pekka Enberg
Cc: Pekka Enberg, Alexander Graf, Avi Kivity, Linus Torvalds,
Ingo Molnar, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers,
Américo Wang, Blue Swirl
On 11/07/11 12:34, Pekka Enberg 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.
perf *is* an exception today.
It might make sense to change that. But IMHO it only makes sense if
there is a really broad agreement on it and other core stuff moves into
the kernel too. Then you'll be able to get advantages out of it. For
example standardizing the process to create an initramfs (using the
userspace tools shipped with the kernel) instead of having each distro
creating its own way.
I somehow doubt we'll see such an broad agreement though. Most people
seem to be happy with the current model. There is a reason why the
klibc + early-userspace-in-kernel-tree project died in the end ...
cheers,
Gerd
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 12:08 ` Gerd Hoffmann
@ 2011-11-07 12:29 ` Ted Ts'o
2011-11-07 12:42 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Ted Ts'o @ 2011-11-07 12:29 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Pekka Enberg, Pekka Enberg, Alexander Graf, Avi Kivity,
Linus Torvalds, Ingo Molnar, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers,
Américo Wang, Blue Swirl
On Mon, Nov 07, 2011 at 01:08:50PM +0100, Gerd Hoffmann wrote:
>
> perf *is* an exception today.
>
> It might make sense to change that. But IMHO it only makes sense if
> there is a really broad agreement on it and other core stuff moves into
> the kernel too. Then you'll be able to get advantages out of it. For
> example standardizing the process to create an initramfs (using the
> userspace tools shipped with the kernel) instead of having each distro
> creating its own way.
I wish distributions had standardized on a single initramfs, sure.
But that doesn't mean that the only way to do this is to merge
userspace code into the kernel source tree. Everybody uses fsck,
originally from the e2fsprogs source tree, and now from util-linux-ng,
and that isn't merged into the kernel sources.
And I think would be actively *harmful* to merge util-linux-ng into
the kernel sources. For a variety of reasons, you may want to upgrade
util-linux-ng, and not the kernel, or the kernel, and not
util-linux-ng. If you package the two sources together, it becomes
unclear what versions of the kernel will work with which versions of
util-linux-ng, and vice versa. Suppose you need to fix a security bug
in some program that lives in util-linux-ng. If it was bundled inside
the kernel, a distribution would now have to release a kernel source
package. Does that mean that it will have to ship the a new set of
kernel binaries? Or does the distribution have to ship multiple
binary packages that derive from the differently versioned source
packages?
And the same problems will exist with kvm-tool. What if you need to
release a new version of kvm-tool? Does that mean that you have to
release a new set of kernel binaries? It's a mess, and there's a
reason why we don't have glibc, e2fsprogs, xfsprogs, util-linux-ng,
etc., all packaged into the kernel sources.
Because it's a stupid, idiotic thing to do.
- Ted
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 12:29 ` Ted Ts'o
@ 2011-11-07 12:42 ` Pekka Enberg
2011-11-07 12:47 ` Ted Ts'o
0 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 12:42 UTC (permalink / raw)
To: Ted Ts'o, Gerd Hoffmann, Pekka Enberg, Pekka Enberg,
Alexander Graf, Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
Hi Ted,
On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o <tytso@mit.edu> wrote:
> And the same problems will exist with kvm-tool. What if you need to
> release a new version of kvm-tool? Does that mean that you have to
> release a new set of kernel binaries? It's a mess, and there's a
> reason why we don't have glibc, e2fsprogs, xfsprogs, util-linux-ng,
> etc., all packaged into the kernel sources.
If we need to release a new version, patches would go through the
-stable tree just like with any other subsystem.
On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o <tytso@mit.edu> wrote:
> Because it's a stupid, idiotic thing to do.
The discussion is turning into whether or not linux/tools makes sense
or not. I wish you guys would have had it before perf was merged to
the tree.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 12:42 ` Pekka Enberg
@ 2011-11-07 12:47 ` Ted Ts'o
2011-11-07 12:59 ` Pekka Enberg
2011-11-07 13:12 ` Pekka Enberg
0 siblings, 2 replies; 88+ messages in thread
From: Ted Ts'o @ 2011-11-07 12:47 UTC (permalink / raw)
To: Pekka Enberg
Cc: Gerd Hoffmann, Pekka Enberg, Alexander Graf, Avi Kivity,
Linus Torvalds, Ingo Molnar, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers,
Américo Wang, Blue Swirl
On Mon, Nov 07, 2011 at 02:42:57PM +0200, Pekka Enberg wrote:
> On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o <tytso@mit.edu> wrote:
> > Because it's a stupid, idiotic thing to do.
>
> The discussion is turning into whether or not linux/tools makes sense
> or not. I wish you guys would have had it before perf was merged to
> the tree.
Perf was IMHO an overreaction caused by the fact that systemtap and
oprofile people packaged and released the sources in a way that kernel
developers didn't like.
I don't think perf should be used as a precendent that now argues that
any new kernel utility should be moved into the kernel sources. Does
it make sense to move all of mount, fsck, login, etc., into the kernel
sources? There are far more kernel tools outside of the kernel
sources than inside the kernel sources.
- Ted
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 12:47 ` Ted Ts'o
@ 2011-11-07 12:59 ` Pekka Enberg
2011-11-07 13:12 ` Pekka Enberg
1 sibling, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 12:59 UTC (permalink / raw)
To: Ted Ts'o, Pekka Enberg, Gerd Hoffmann, Pekka Enberg,
Alexander Graf, Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o <tytso@mit.edu> wrote:
> Perf was IMHO an overreaction caused by the fact that systemtap and
> oprofile people packaged and released the sources in a way that kernel
> developers didn't like.
>
> I don't think perf should be used as a precendent that now argues that
> any new kernel utility should be moved into the kernel sources. Does
> it make sense to move all of mount, fsck, login, etc., into the kernel
> sources? There are far more kernel tools outside of the kernel
> sources than inside the kernel sources.
There's two overlapping questions here:
(1) Does it make sense to merge the KVM tool to Linux kernel tree?
(2) Does it make sense to merge userspace tools to the kernel tree?
I'm not trying to use perf to justify merging the KVM tool. However, you
seem to be arguing that it shouldn't be merged because merging
userspace tools in general doesn't make sense. That's why I brought up
the situation with perf.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 12:47 ` Ted Ts'o
2011-11-07 12:59 ` Pekka Enberg
@ 2011-11-07 13:12 ` Pekka Enberg
2011-11-08 13:29 ` Karel Zak
1 sibling, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-07 13:12 UTC (permalink / raw)
To: Ted Ts'o, Pekka Enberg, Gerd Hoffmann, Pekka Enberg,
Alexander Graf, Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o <tytso@mit.edu> wrote:
> I don't think perf should be used as a precendent that now argues that
> any new kernel utility should be moved into the kernel sources. Does
> it make sense to move all of mount, fsck, login, etc., into the kernel
> sources? There are far more kernel tools outside of the kernel
> sources than inside the kernel sources.
You seem to think that the KVM tool was developed in isolation and we
simply copied the code to tools/kvm for the pull request. That's simply
not true. We've done a lot of work to make the code feel like kernel code
from locking primitive APIs to serial console emulation register names.
We really consider KVM tool to be a new Linux subsystem. It's the long
lost cousin or bastard child of KVM, depending on who you ask.
I don't know if it makes sense to merge the tools you've mentioned above.
My gut feeling is that it's probably not reasonable - there's already a
community working on it with their own development process and coding
style. I don't think there's a simple answer to this but I don't agree with
your rather extreme position that all userspace tools should be kept out
of the kernel tree.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-07 13:12 ` Pekka Enberg
@ 2011-11-08 13:29 ` Karel Zak
2011-11-08 14:30 ` Pekka Enberg
0 siblings, 1 reply; 88+ messages in thread
From: Karel Zak @ 2011-11-08 13:29 UTC (permalink / raw)
To: Pekka Enberg
Cc: Ted Ts'o, Gerd Hoffmann, Pekka Enberg, Alexander Graf,
Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On Mon, Nov 07, 2011 at 03:12:28PM +0200, Pekka Enberg wrote:
> On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o <tytso@mit.edu> wrote:
> > I don't think perf should be used as a precendent that now argues that
> > any new kernel utility should be moved into the kernel sources. Does
> > it make sense to move all of mount, fsck, login, etc., into the kernel
> > sources? There are far more kernel tools outside of the kernel
> > sources than inside the kernel sources.
[...]
> I don't know if it makes sense to merge the tools you've mentioned above.
> My gut feeling is that it's probably not reasonable - there's already a
> community working on it with their own development process and coding
> style. I don't think there's a simple answer to this but I don't agree with
> your rather extreme position that all userspace tools should be kept out
> of the kernel tree.
Ted's position is not extreme. He follows the simple and exactly defined
border between userspace and kernel. The native userspace feature is
variability and substitutability.
The util-linux package is really nice example:
- you don't have to use it, you can use busybox
- we have currently three implementation of login(1), many getty
implementations, etc.
- it's normal that people use the latest util-linux releases with very
old kernels (in year 2008 I had report from person with kernel 2.4:-)
- userspace is very often about portability -- it's crazy, but some people
use some utils from util-linux on Hurd, Solaris and BSD (including very
Linux specific things like mkswap and hwclock)
Anyway, I agree that small one-man projects are ineffective for
important system tools -- it's usually better to merge things into
large projects with reliable infrastructure and alive community (here
I agree with Lennart's idea to have 3-5 projects for whole low-level
userspace).
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-08 13:29 ` Karel Zak
@ 2011-11-08 14:30 ` Pekka Enberg
0 siblings, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-08 14:30 UTC (permalink / raw)
To: Karel Zak
Cc: Ted Ts'o, Gerd Hoffmann, Alexander Graf, Avi Kivity,
Linus Torvalds, Ingo Molnar, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers,
Américo Wang, Blue Swirl
On Tue, Nov 8, 2011 at 3:29 PM, Karel Zak <kzak@redhat.com> wrote:
>> I don't know if it makes sense to merge the tools you've mentioned above.
>> My gut feeling is that it's probably not reasonable - there's already a
>> community working on it with their own development process and coding
>> style. I don't think there's a simple answer to this but I don't agree with
>> your rather extreme position that all userspace tools should be kept out
>> of the kernel tree.
>
> Ted's position is not extreme. He follows the simple and exactly defined
> border between userspace and kernel. The native userspace feature is
> variability and substitutability.
It's an extreme position because he's arguing that we should only have
kernel code in the tree or we need open up to all userspace code.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 12:43 ` Avi Kivity
2011-11-06 13:06 ` Pekka Enberg
@ 2011-11-06 13:11 ` Pekka Enberg
1 sibling, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 13:11 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity <avi@redhat.com> wrote:
> Alex's script, though, is just a few dozen lines. kvm-tool is a 20K
> patch - in fact 2X as large as kvm when it was first merged. And it's
> main feature seems to be that "it is not qemu".
I think I've mentioned many times that I find the QEMU source terribly
difficult to read and hack on. So if you mean "not qemu" from that
point of view, sure, I think it's a very important point. The command
line interface is also "not qemu" for a very good reason too.
As for virtio drivers and such, we're actually following QEMU's
example very closely. I guess we're going to diverge a bit for better
guest isolation but fundamentally I don't see why we'd want to be
totally different from QEMU on that level.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 11:50 ` Avi Kivity
2011-11-06 12:14 ` Pekka Enberg
@ 2011-11-06 12:27 ` Pekka Enberg
1 sibling, 0 replies; 88+ messages in thread
From: Pekka Enberg @ 2011-11-06 12:27 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Américo Wang, Blue Swirl
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity <avi@redhat.com> wrote:
> So far, kvm-tool capabilities are a subset of qemu's. Does it add
> anything beyond a different command-line?
I think "different command line" is a big thing which is why we've
spent so much time on it. But if you mean other end user features, no,
we don't add anything new on the table right now. I think our
userspace networking implementation is better than QEMU's slirp but
that's purely technical thing.
I also don't think we should add new features for their own sake.
Linux virtualization isn't a terribly difficult thing to do thanks to
KVM and virtio drivers. I think most of the big ticket items will be
doing things like improving guest isolation and making guests more
accessible to the host.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-06 1:35 Alexander Graf
2011-11-06 10:04 ` Pekka Enberg
@ 2011-11-08 14:41 ` Avi Kivity
2011-11-08 14:52 ` Christoph Hellwig
1 sibling, 1 reply; 88+ messages in thread
From: Avi Kivity @ 2011-11-08 14:41 UTC (permalink / raw)
To: Alexander Graf
Cc: Linus Torvalds, Ingo Molnar, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers, Pekka Enberg,
Américo Wang, Blue Swirl
On 11/06/2011 03:35 AM, Alexander Graf wrote:
> 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.
>
Doesn't work on Fedora 15. F15's qemu-kvm doesn't have -machine or
-virtfs. Even qemu.git on F15 won't build virtfs since xattr.h
detection is broken (patch posted).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-08 14:41 ` Avi Kivity
@ 2011-11-08 14:52 ` Christoph Hellwig
2011-11-08 14:55 ` Sasha Levin
` (3 more replies)
0 siblings, 4 replies; 88+ messages in thread
From: Christoph Hellwig @ 2011-11-08 14:52 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Pekka Enberg, Am?rico Wang, Blue Swirl
On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
> On 11/06/2011 03:35 AM, Alexander Graf wrote:
> > 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.
> >
>
> Doesn't work on Fedora 15. F15's qemu-kvm doesn't have -machine or
> -virtfs. Even qemu.git on F15 won't build virtfs since xattr.h
> detection is broken (patch posted).
Nevermind that running virtfs as a rootfs is a really dumb idea. You
do now want to run a VM that has a rootfs that gets changed all the
time behind your back.
Running qemu -snapshot on the actual root block device is the only
safe way to reuse the host installation, although it gets a bit
complicated if people have multiple devices mounted into the namespace.
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-08 14:52 ` Christoph Hellwig
@ 2011-11-08 14:55 ` Sasha Levin
2011-11-08 14:57 ` Avi Kivity
` (2 subsequent siblings)
3 siblings, 0 replies; 88+ messages in thread
From: Sasha Levin @ 2011-11-08 14:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Pekka Enberg, Am?rico Wang, Blue Swirl
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
>> On 11/06/2011 03:35 AM, Alexander Graf wrote:
>> > 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.
>> >
>>
>> Doesn't work on Fedora 15. F15's qemu-kvm doesn't have -machine or
>> -virtfs. Even qemu.git on F15 won't build virtfs since xattr.h
>> detection is broken (patch posted).
>
> Nevermind that running virtfs as a rootfs is a really dumb idea. You
> do now want to run a VM that has a rootfs that gets changed all the
> time behind your back.
>
> Running qemu -snapshot on the actual root block device is the only
> safe way to reuse the host installation, although it gets a bit
> complicated if people have multiple devices mounted into the namespace.
Using block devices also requires root.
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-08 14:52 ` Christoph Hellwig
2011-11-08 14:55 ` Sasha Levin
@ 2011-11-08 14:57 ` Avi Kivity
2011-11-08 14:59 ` Christoph Hellwig
2011-11-08 15:04 ` Jan Kiszka
2011-11-08 15:26 ` Pekka Enberg
3 siblings, 1 reply; 88+ messages in thread
From: Avi Kivity @ 2011-11-08 14:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Pekka Enberg, Am?rico Wang, Blue Swirl
On 11/08/2011 04:52 PM, Christoph Hellwig wrote:
> On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
> > On 11/06/2011 03:35 AM, Alexander Graf wrote:
> > > 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.
> > >
> >
> > Doesn't work on Fedora 15. F15's qemu-kvm doesn't have -machine or
> > -virtfs. Even qemu.git on F15 won't build virtfs since xattr.h
> > detection is broken (patch posted).
>
> Nevermind that running virtfs as a rootfs is a really dumb idea. You
> do now want to run a VM that has a rootfs that gets changed all the
> time behind your back.
True.
> Running qemu -snapshot on the actual root block device is the only
> safe way to reuse the host installation, although it gets a bit
> complicated if people have multiple devices mounted into the namespace.
How is -snapshot any different? If the host writes a block after the
guest has been launched, but before that block was cowed, then the guest
will see the new block.
It could work with a btrfs snapshot, but not everyone uses that.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-08 14:57 ` Avi Kivity
@ 2011-11-08 14:59 ` Christoph Hellwig
2011-11-08 17:34 ` Alexander Graf
0 siblings, 1 reply; 88+ messages in thread
From: Christoph Hellwig @ 2011-11-08 14:59 UTC (permalink / raw)
To: Avi Kivity
Cc: Christoph Hellwig, Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Pekka Enberg, Am?rico Wang, Blue Swirl
On Tue, Nov 08, 2011 at 04:57:04PM +0200, Avi Kivity wrote:
> > Running qemu -snapshot on the actual root block device is the only
> > safe way to reuse the host installation, although it gets a bit
> > complicated if people have multiple devices mounted into the namespace.
>
> How is -snapshot any different? If the host writes a block after the
> guest has been launched, but before that block was cowed, then the guest
> will see the new block.
Right, thinko - qemu's snapshots are fairly useless due to sitting
ontop of the file to be modified.
> It could work with a btrfs snapshot, but not everyone uses that.
Or LVM snapshot. Either way, just reusing the root fs without care
is a dumb idea, and I really don't want any tool or script that
encurages such braindead behaviour in the kernel tree.
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-08 14:59 ` Christoph Hellwig
@ 2011-11-08 17:34 ` Alexander Graf
2011-11-08 17:36 ` Avi Kivity
0 siblings, 1 reply; 88+ messages in thread
From: Alexander Graf @ 2011-11-08 17:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Pekka Enberg, Am?rico Wang, Blue Swirl
On 11/08/2011 03:59 PM, Christoph Hellwig wrote:
> On Tue, Nov 08, 2011 at 04:57:04PM +0200, Avi Kivity wrote:
>>> Running qemu -snapshot on the actual root block device is the only
>>> safe way to reuse the host installation, although it gets a bit
>>> complicated if people have multiple devices mounted into the namespace.
>> How is -snapshot any different? If the host writes a block after the
>> guest has been launched, but before that block was cowed, then the guest
>> will see the new block.
> Right, thinko - qemu's snapshots are fairly useless due to sitting
> ontop of the file to be modified.
>
>> It could work with a btrfs snapshot, but not everyone uses that.
> Or LVM snapshot. Either way, just reusing the root fs without care
> is a dumb idea, and I really don't want any tool or script that
> encurages such braindead behaviour in the kernel tree.
Heh, yeah, the intent was obviously to have a separate rootfs tree
somewhere in a directory. But that's not available at first when running
this, so I figured for a simple "get me rolling" FAQ directing the
guest's rootfs to / at least gets you somewhere (especially when run as
user with init=/bin/bash).
Alex
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-08 17:34 ` Alexander Graf
@ 2011-11-08 17:36 ` Avi Kivity
0 siblings, 0 replies; 88+ messages in thread
From: Avi Kivity @ 2011-11-08 17:36 UTC (permalink / raw)
To: Alexander Graf
Cc: Christoph Hellwig, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Pekka Enberg, Am?rico Wang, Blue Swirl
On 11/08/2011 07:34 PM, Alexander Graf wrote:
>>
>>> It could work with a btrfs snapshot, but not everyone uses that.
>> Or LVM snapshot. Either way, just reusing the root fs without care
>> is a dumb idea, and I really don't want any tool or script that
>> encurages such braindead behaviour in the kernel tree.
>
>
> Heh, yeah, the intent was obviously to have a separate rootfs tree
> somewhere in a directory. But that's not available at first when
> running this, so I figured for a simple "get me rolling" FAQ directing
> the guest's rootfs to / at least gets you somewhere (especially when
> run as user with init=/bin/bash).
>
Right, init=/bin/bash is not too insane for rootfs passthrough.
/proc will be completely broken though, need to mount the guest's.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-08 14:52 ` Christoph Hellwig
2011-11-08 14:55 ` Sasha Levin
2011-11-08 14:57 ` Avi Kivity
@ 2011-11-08 15:04 ` Jan Kiszka
2011-11-08 15:26 ` Pekka Enberg
3 siblings, 0 replies; 88+ messages in thread
From: Jan Kiszka @ 2011-11-08 15:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Pekka Enberg, Am?rico Wang, Blue Swirl,
Aneesh Kumar K.V
[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]
On 2011-11-08 15:52, Christoph Hellwig wrote:
> On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
>> On 11/06/2011 03:35 AM, Alexander Graf wrote:
>>> 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.
>>>
>>
>> Doesn't work on Fedora 15. F15's qemu-kvm doesn't have -machine or
>> -virtfs. Even qemu.git on F15 won't build virtfs since xattr.h
>> detection is broken (patch posted).
>
> Nevermind that running virtfs as a rootfs is a really dumb idea. You
> do now want to run a VM that has a rootfs that gets changed all the
> time behind your back.
>
> Running qemu -snapshot on the actual root block device is the only
> safe way to reuse the host installation, although it gets a bit
> complicated if people have multiple devices mounted into the namespace.
I thought about this while hacking a slide on this topic: It's clumsy
(compared to -snapshot - my favorite one as well), but you could use
some snapshot on the host fs. Or a union fs (if we had an official one)
with the write layer directed to some tmpfs area.
But what we likely rather want (as it would work without privileges) is
built-in write redirection for virtfs. Not an expert on this, but I
guess that will have to solve the same problems an in-kernel union fs
solution faces, no?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-08 14:52 ` Christoph Hellwig
` (2 preceding siblings ...)
2011-11-08 15:04 ` Jan Kiszka
@ 2011-11-08 15:26 ` Pekka Enberg
2011-11-08 15:28 ` Christoph Hellwig
3 siblings, 1 reply; 88+ messages in thread
From: Pekka Enberg @ 2011-11-08 15:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, Alexander Graf, Linus Torvalds, Ingo Molnar,
linux-kernel@vger.kernel.org List, kvm@vger.kernel.org list,
qemu-devel Developers, Am?rico Wang, Blue Swirl
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig <hch@infradead.org> wrote:
> Nevermind that running virtfs as a rootfs is a really dumb idea. You
> do now want to run a VM that has a rootfs that gets changed all the
> time behind your back.
It's rootfs binaries that are shared, not configuration. It's
unfortunate but works OK for the single user use case it's meant for.
It's obviously not a proper solution for the generic case. We were
hoping that we could use something like overlayfs to hide the issue
under the rug. Do you think that's also a really dumb thing to do?
Using block device snapshotting would be interesting and we should
definitely look into that.
Pekka
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels
2011-11-08 15:26 ` Pekka Enberg
@ 2011-11-08 15:28 ` Christoph Hellwig
0 siblings, 0 replies; 88+ messages in thread
From: Christoph Hellwig @ 2011-11-08 15:28 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Hellwig, Avi Kivity, Alexander Graf, Linus Torvalds,
Ingo Molnar, linux-kernel@vger.kernel.org List,
kvm@vger.kernel.org list, qemu-devel Developers, Am?rico Wang,
Blue Swirl
On Tue, Nov 08, 2011 at 05:26:03PM +0200, Pekka Enberg wrote:
> On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig <hch@infradead.org> wrote:
> > Nevermind that running virtfs as a rootfs is a really dumb idea. ?You
> > do now want to run a VM that has a rootfs that gets changed all the
> > time behind your back.
>
> It's rootfs binaries that are shared, not configuration. It's
> unfortunate but works OK for the single user use case it's meant for.
> It's obviously not a proper solution for the generic case. We were
> hoping that we could use something like overlayfs to hide the issue
> under the rug. Do you think that's also a really dumb thing to do?
It doesn't hide your issues. Any kind of unioning will have massive
consistency issues (as in will corrupt your fs if you do stupid things)
if the underlying layer is allowed to be written to. Thus all the
fuzz about making sure the underlying fs can never be mounted writeable
in the union mount patches.
^ permalink raw reply [flat|nested] 88+ messages in thread
* [PATCH] KVM: Add wrapper script around QEMU to test kernels
@ 2012-05-11 15:46 Alexander Graf
0 siblings, 0 replies; 88+ messages in thread
From: Alexander Graf @ 2012-05-11 15:46 UTC (permalink / raw)
To: kvm@vger.kernel.org list
Cc: Linus Torvalds, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Avi Kivity,
Andreas Färber
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:
$ ./tools/testing/run-qemu/run-qemu.sh -r / -a init=/bin/bash
This will drop you into a shell on your rootfs.
Or you can also use a ready made image:
$ IMG=http://people.debian.org/~aurel32/qemu/amd64
$ IMG="$IMG/debian_squeeze_amd64_standard.qcow2"
$ ./tools/testing/run-qemu/run-qemu.sh -d $IMG \
-a "root=/dev/vda1 init=/bin/bash"
Keep in mind that http is read-only, so no writing to the image :).
Either way, you provide the kernel. QEMU provides the test environment!
Easy, eh?
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
v2 -> v3:
- move to tools/testing
- fix running: message
v3 -> v4:
- update to new path everywhere
- check for sd module in ide case
- fix -a
- simplify KERNEL_BIN setting code
- check for qemu-system-i386
- require CONFIG_9P_FS in 9p case
- add QEMU version check
- check for success of drive_if
- mention QEMU_BIN environment variable in help
---
tools/testing/run-qemu/run-qemu.sh | 361 ++++++++++++++++++++++++++++++++++++
1 files changed, 361 insertions(+), 0 deletions(-)
create mode 100755 tools/testing/run-qemu/run-qemu.sh
diff --git a/tools/testing/run-qemu/run-qemu.sh b/tools/testing/run-qemu/run-qemu.sh
new file mode 100755
index 0000000..f4fa6e7
--- /dev/null
+++ b/tools/testing/run-qemu/run-qemu.sh
@@ -0,0 +1,361 @@
+#!/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:
+#
+# $ ./tools/testing/run-qemu/run-qemu.sh -r /
+#
+# Run the same with SDL:
+#
+# $ ./tools/testing/run-qemu/run-qemu.sh -r / --sdl
+#
+# Or with a PPC build:
+#
+# $ ARCH=ppc ./tools/testing/run-qemu/run-qemu.sh -r /
+#
+# PPC with a mac99 model by passing options to QEMU:
+#
+# $ ARCH=ppc ./tools/testing/run-qemu/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:
+ $ ./tools/testing/run-qemu/run-qemu.sh -r /
+
+ Run the same with SDL:
+ $ ./tools/testing/run-qemu/run-qemu.sh -r / --sdl
+
+ Or with a PPC build:
+ $ ARCH=ppc ./tools/testing/run-qemu/run-qemu.sh -r /
+
+ PPC with a mac99 model by passing options to QEMU:
+ $ ARCH=ppc ./tools/testing/run-qemu/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
+ require_config "BLK_DEV_SD"
+ echo ide
+ else
+ echo "\
+Your kernel must have either VIRTIO_BLK or ATA_PIIX
+enabled for block device assignment" >&2
+ exit 1
+ fi
+}
+
+function verify_qemu() {
+ QEMU="$(which $1 2>/dev/null)"
+
+ # binary exists?
+ [ -x "$QEMU" ] || exit 1
+
+ # we need a version that knows -machine
+ if ! "$QEMU" --help | grep -q -- '-machine'; then
+ exit 1
+ fi
+
+ echo "$QEMU"
+ exit 0
+}
+
+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 $2"
+ shift
+ ;;
+ -d|--disk)
+ set -e
+ QEMU_OPTIONS="$QEMU_OPTIONS -drive \
+ file=$2,if=$(drive_if),cache=unsafe"
+ set +e
+ 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)
+ # SUSE and Red Hat call the binary qemu-kvm
+ [ "$QEMU_BIN" ] || QEMU_BIN=$(verify_qemu qemu-kvm)
+
+ # Debian and Gentoo call it kvm
+ [ "$QEMU_BIN" ] || QEMU_BIN=$(verify_qemu kvm)
+
+ # QEMU's own build system calls it qemu-system-x86_64
+ [ "$QEMU_BIN" ] || QEMU_BIN=$(verify_qemu qemu-system-x86_64)
+ ;;
+i*86)
+ # SUSE and Red Hat call the binary qemu-kvm
+ [ "$QEMU_BIN" ] || QEMU_BIN=$(verify_qemu qemu-kvm)
+
+ # Debian and Gentoo call it kvm
+ [ "$QEMU_BIN" ] || QEMU_BIN=$(verify_qemu kvm)
+
+ # new i386 version of QEMU
+ [ "$QEMU_BIN" ] || QEMU_BIN=$(verify_qemu qemu-system-i386)
+
+ # i386 version of QEMU
+ [ "$QEMU_BIN" ] || QEMU_BIN=$(verify_qemu qemu)
+ ;;
+s390*)
+ KERNEL_BIN=arch/s390/boot/image
+ [ "$QEMU_BIN" ] || QEMU_BIN=$(verify_qemu qemu-system-s390x)
+ ;;
+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
+
+or point this script to a working version of qemu using
+
+ $ export QEMU_BIN=/path/to/qemu-kvm
+" >&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"
+ require_config "9P_FS"
+ 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 -n " Executing: $QEMU_BIN $QEMU_OPTIONS -append \"$KERNEL_APPEND\" "
+for i in "$@"; do
+ echo -n "\"$i\" "
+done
+echo
+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=$(( $$ + 1024 ))
+ xterm -T "$BASENAME" -e "sleep 2; gdb vmlinux -ex 'target remote localhost:$PORT' -ex c" &
+ GDB_PID=$!
+ QEMU_OPTIONS="$QEMU_OPTIONS -gdb tcp::$PORT"
+fi
+
+$QEMU_BIN $QEMU_OPTIONS -append "$KERNEL_APPEND" "$@"
+wait $GDB_PID &>/dev/null
+
--
1.6.0.2
^ permalink raw reply related [flat|nested] 88+ messages in thread
end of thread, other threads:[~2012-05-11 15:46 UTC | newest]
Thread overview: 88+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-08-23 22:16 [PATCH] KVM: Add wrapper script around Qemu to test kernels Alexander Graf
2011-08-24 5:19 ` Pekka Enberg
2011-08-24 5:31 ` Américo Wang
2011-08-24 20:35 ` Alexander Graf
2011-08-25 3:44 ` Américo Wang
2011-11-05 23:47 ` Alexander Graf
2011-08-24 8:25 ` Avi Kivity
2011-08-24 9:16 ` Jan Kiszka
2011-08-24 21:06 ` Alexander Graf
2011-08-24 17:40 ` [Qemu-devel] " Blue Swirl
2011-08-24 19:17 ` Avi Kivity
2011-08-24 21:17 ` Alexander Graf
-- strict thread matches above, loose matches on Subject: below --
2011-08-24 21:38 [PATCH] KVM: Add wrapper script around QEMU " Alexander Graf
2011-11-06 13:54 ` Jan Kiszka
2012-05-11 13:42 ` Alexander Graf
2012-05-11 14:05 ` Jan Kiszka
2011-11-06 1:35 Alexander Graf
2011-11-06 10:04 ` Pekka Enberg
2011-11-06 10:07 ` Avi Kivity
2011-11-06 10:12 ` Pekka Enberg
2011-11-06 10:23 ` Avi Kivity
2011-11-06 11:08 ` Pekka Enberg
2011-11-06 11:50 ` Avi Kivity
2011-11-06 12:14 ` Pekka Enberg
2011-11-06 12:27 ` Avi Kivity
2011-11-06 12:32 ` Pekka Enberg
2011-11-06 12:43 ` Avi Kivity
2011-11-06 13:06 ` Pekka Enberg
2011-11-06 15:56 ` Avi Kivity
2011-11-06 16:35 ` Pekka Enberg
2011-11-06 16:50 ` Avi Kivity
2011-11-06 16:19 ` Jan Kiszka
2011-11-06 16:30 ` Pekka Enberg
2011-11-06 16:39 ` Jan Kiszka
2011-11-06 17:11 ` Pekka Enberg
2011-11-06 17:23 ` Jan Kiszka
2011-11-06 17:55 ` Pekka Enberg
2011-11-06 16:39 ` Pekka Enberg
2011-11-07 10:11 ` Gerd Hoffmann
2011-11-07 10:18 ` Pekka Enberg
2011-11-06 17:15 ` Alexander Graf
2011-11-06 17:28 ` Pekka Enberg
2011-11-06 17:30 ` Alexander Graf
2011-11-06 18:05 ` Pekka Enberg
2011-11-06 19:14 ` Paolo Bonzini
2011-11-06 19:19 ` Pekka Enberg
2011-11-06 22:08 ` Frank Ch. Eigler
2011-11-07 6:58 ` Pekka Enberg
2011-11-06 19:11 ` Paolo Bonzini
2011-11-06 19:17 ` Pekka Enberg
2011-11-06 20:01 ` Paolo Bonzini
2011-11-06 20:17 ` Pekka Enberg
2011-11-07 8:00 ` Paolo Bonzini
2011-11-07 8:09 ` Pekka Enberg
2011-11-07 8:20 ` Paolo Bonzini
2011-11-07 8:45 ` Pekka Enberg
2011-11-07 8:52 ` Paolo Bonzini
2011-11-07 8:57 ` Pekka Enberg
2011-11-07 8:13 ` Pekka Enberg
2011-11-06 20:31 ` Pekka Enberg
2011-11-07 10:23 ` Gerd Hoffmann
2011-11-07 10:30 ` [Qemu-devel] " Sasha Levin
2011-11-07 11:02 ` Paolo Bonzini
2011-11-07 11:44 ` Pekka Enberg
2011-11-07 12:18 ` Gerd Hoffmann
2011-11-07 12:21 ` Pekka Enberg
2011-11-07 11:34 ` Pekka Enberg
2011-11-07 11:57 ` Ingo Molnar
2011-11-07 12:08 ` Gerd Hoffmann
2011-11-07 12:29 ` Ted Ts'o
2011-11-07 12:42 ` Pekka Enberg
2011-11-07 12:47 ` Ted Ts'o
2011-11-07 12:59 ` Pekka Enberg
2011-11-07 13:12 ` Pekka Enberg
2011-11-08 13:29 ` Karel Zak
2011-11-08 14:30 ` Pekka Enberg
2011-11-06 13:11 ` Pekka Enberg
2011-11-06 12:27 ` Pekka Enberg
2011-11-08 14:41 ` Avi Kivity
2011-11-08 14:52 ` Christoph Hellwig
2011-11-08 14:55 ` Sasha Levin
2011-11-08 14:57 ` Avi Kivity
2011-11-08 14:59 ` Christoph Hellwig
2011-11-08 17:34 ` Alexander Graf
2011-11-08 17:36 ` Avi Kivity
2011-11-08 15:04 ` Jan Kiszka
2011-11-08 15:26 ` Pekka Enberg
2011-11-08 15:28 ` Christoph Hellwig
2012-05-11 15:46 Alexander Graf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox