Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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 ag...@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 000..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)
+
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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 ag...@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 000..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)
+
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
* Vince Weaver vi...@deater.net wrote: On Mon, 7 Nov 2011, Ingo Molnar wrote: I think we needed to do only one revert along the way in the past two years, to fix an unintended ABI breakage in PowerTop. Considering the total complexity of the perf ABI our compatibility track record is *very* good. There have been more breakages, as you know. It's just they weren't caught in time so they were declared to be grandfathered in rather than fixed. I remember one such instance were you reported a 'regression' that spanned several -stable kernel releases - and unless the fix is easy and obvious that's the regular upstream treatment. As Linus said it too on the recent Kernel Summit an ABI is only an ABI if it's actually *used*. But there's more, you've repeatedly rejected our offer to extend 'perf test' to cover the functionality that your library relies on. If you refuse to timely test newer upstream kernels while you rely on obscure details that nobody else uses and if you refuse to make your testcases more prominent it becomes *your* problem. There's not much we can do if you refuse to test and refuse to push your testcases upstream ... ... and you have argued against perf from the very first day on, when you were one of the perfmon developers - and IMO in hindsight you've been repeatedly wrong about most of your design arguments. I can't find an exact e-mail, but I seem to recall my arguments were that Pentium 4 support would be hard (it was), [...] To the contrary, a single person implemented most of it, out of curiosity. [...] that in-kernel generalized events were a bad idea (I still think that, try talking to the ARM guys sometime about that) [...] To the contrary, generalized events work very well and they are one of the reasons why the perf tooling is so usable. [...] and that making access to raw events hard (by not using a naming library) was silly. [...] To the contrary, by 'making it easy' you mean 'translate hexa codes to vendor specific gibberish' which is hardly any better to actual users of the tool and gives the false appearance of being a solution. All in one you advocated all the oprofile design mistakes and you have been proven thoroughly wrong by reality. The PAPI project has the (fundamental) problem that you are still doing it in the old-style sw design fashion, with many months long delays in testing, and then you are blaming the problems you inevitably meet with that model on *us*. The fundamental problem with the PAPI project is that we only have 3 full-time developers, and we have to make sure PAPI runs on about 10 different platforms, of which perf_events/Linux is only one. Time I waste tracking down perf_event ABI regressions and DoS bugs takes away from actual useful userspace PAPI development. If people are not interested in even testing the basic test-suite of PAPI on a recent kernel then i'm afraid there must be something very wrong with the PAPI project structure. Somehow that testing is not missing from the perf tool, despite it being a much younger and smaller project. Did you ever stop to think why that is so? There was one PAPI incident i remember where it took you several *months* to report a regression in a regular PAPI test-case (no actual app affected as far as i know). No other tester ever ran the PAPI testcases so nobody else reported it. We have a huge userbase. They run on some pretty amazing machines and do some tests that strain perf libraries to the limit. They also tend to use distro kernels, assuming they even have moved to 2.6.31+ kernels yet. When these power users report problems, they aren't going to be against the -tip tree. Nobody expects you to test the -tip tree if you don't want to (it would certainly be useful to you if you are interested in PMU development), but there's a 2.5 months stabilization window after the upstream merge. Nobody but you tests PAPI so you need to become *part* of the upstream development process, which releases a new upstream kernel every 3 months. PAPI is a free software project, with the devel tree available from CVS. It takes maybe 15 minutes to run the full PAPI regression suite. I encourage you or any perf developer to try it and report any issues. I will fix what gets reported and neither i nor other regular kernel testers actually use it. You really need to do more testing to fill that gap, expecting others to volunteer time into a project they don't actually use is extremely backwards... I can only be so comprehensive. I didn't find the current NMI-watchdog regression right away because my git tree builds didn't have it enabled. It wasn't until there started being 3.0 distro kernels that people started reporting the problem to us. Also, as i mentioned it several times before, you are free to add an arbitrary number of ABI test-cases to 'perf test' and we can
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu: * Vince Weaver vi...@deater.net wrote: as mentioned before I have my own perf_event test suite with 20+ tests. http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html That should probably be moved into perf test. Arnaldo, any objections? I'd gladly take patches, I even have in my TODO list for me to volunteer time to do that at some point. If somebody else than me or Vince wants to do that... Assuming there is no licensing problem and Vince doesn't objects for that to be done. I know that at least the QE team at Red Hat uses it and I hope other QE teams do it. - Arnaldo
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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 ty...@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 k...@redhat.com http://karelzak.blogspot.com
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Tue, Nov 8, 2011 at 3:29 PM, Karel Zak k...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig h...@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.
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig h...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Tue, Nov 08, 2011 at 05:26:03PM +0200, Pekka Enberg wrote: On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig h...@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.
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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.
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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.
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Tue, 8 Nov 2011, Arnaldo Carvalho de Melo wrote: Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu: * Vince Weaver vi...@deater.net wrote: as mentioned before I have my own perf_event test suite with 20+ tests. http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html That should probably be moved into perf test. Arnaldo, any objections? I'd gladly take patches, I even have in my TODO list for me to volunteer time to do that at some point. If somebody else than me or Vince wants to do that... Assuming there is no licensing problem and Vince doesn't objects for that to be done. I have no objections, though I don't really have time right now to do the work myself. The test code is licensed dual GPLv2/BSD. I should stick that in the package somewhere if I haven't already. My testcases mostly are testing things necessary for proper PAPI functionality and are by no means complete. There are huge areas of perf_event functionality that are not well tested, especially the overflow code. Vince
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini pbonz...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini pbonz...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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 pbonz...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann kra...@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 kra...@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 kra...@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 kra...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Am 06.11.2011 19:31, schrieb Ted Ts'o: On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote: I'm quite happy with KVM tool and hope they continue working on it. My only real wish is that they wouldn't copy QEMU so much and would try bolder things that are fundamentally different from QEMU. My big wish is that they don't try to merge the KVM tool into the kernel code. It's a separate userspace project, and there's no reason for it to be bundled with kernel code. It just makes the kernel sources larger. In fact, the reverse is true as well: It makes kvm-tool's sources larger. Instead on just cloning a small repository I need to clone the whole kernel repository, even though I'm not a kernel developer and don't intend to touch anything but tools/kvm. Not too bad for me as I have a kernel repository lying around anyway and I can share most of the content, but there are people who don't. Still, having an additional 1.2 GB repository just for ~1 MB in which I'm really interested doesn't make me too happy. And dealing with a huge repository also means that even git becomes slower (which means, I had to turn off some functionality for my shell prompt in this repo, as I didn't like waiting for much more than a second or two) Makes it a lot less hackable for me unless you want to restrict the set of potential developers to Linux kernel developers... Kevin
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 7, 2011 at 12:23 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, It's not just about code, it's as much about culture and development process. Indeed. The BSDs have both kernel and the base system in a single repository. There are probably good reasons for (and against) it. In Linux we don't have that culture. No tool (except perf) lives in the kernel repo. I fail to see why kvm-tool is that much different from udev, util-linux, iproute, filesystem tools, that it should be included. tools/power was merged in just 2 versions ago, do you think that merging that was a mistake?
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, 7 Nov 2011, Kevin Wolf wrote: Makes it a lot less hackable for me unless you want to restrict the set of potential developers to Linux kernel developers... We're not restricting potential developers to Linux kernel folks. We're making it easy for them because we believe that the KVM tool is a userspace component that requires the kind of low-level knowledge Linux kernel developers have. I think you're looking at the KVM tool with your QEMU glasses on without realizing that there's no point in comparing the two: we only support Linux on Linux and we avoid hardware emulation as much as possible. So what makes sense for QEMU, doesn't necessarily translate to the KVM tool project. Pekka
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini pbonz...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Am 07.11.2011 12:38, schrieb Pekka Enberg: On Mon, 7 Nov 2011, Kevin Wolf wrote: Makes it a lot less hackable for me unless you want to restrict the set of potential developers to Linux kernel developers... We're not restricting potential developers to Linux kernel folks. We're making it easy for them because we believe that the KVM tool is a userspace component that requires the kind of low-level knowledge Linux kernel developers have. I think you're looking at the KVM tool with your QEMU glasses on without realizing that there's no point in comparing the two: we only support Linux on Linux and we avoid hardware emulation as much as possible. So what makes sense for QEMU, doesn't necessarily translate to the KVM tool project. I'm not comparing anything. I'm not even referring to the virtualization functionality of it. It could be doing anything else and it wouldn't make a difference. For KVM tool I am not much more than a mere user. Trying it out was tedious for me, as it is for anyone else who isn't a kernel developer. That's all I'm saying. Making things easier for some kernel developers but ignoring that at the same time it makes things harder for users I consider a not so clever move. Just wanted to point that out; feel free to ignore it, your priorities are probably different. Kevin
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
* Pekka Enberg penb...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/07/11 12:44, Pekka Enberg wrote: On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini pbonz...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 7, 2011 at 2:18 PM, Gerd Hoffmann kra...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/07/2011 12:30 PM, Sasha Levin wrote: On Mon, Nov 7, 2011 at 12:23 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, It's not just about code, it's as much about culture and development process. Indeed. The BSDs have both kernel and the base system in a single repository. There are probably good reasons for (and against) it. In Linux we don't have that culture. No tool (except perf) lives in the kernel repo. I fail to see why kvm-tool is that much different from udev, util-linux, iproute, filesystem tools, that it should be included. tools/power was merged in just 2 versions ago, do you think that merging that was a mistake? Things like tools/power may make sense, most of the code is tied to the kernel interfaces. tools/kvm is 20k lines and is likely to be 40k+ lines or more before it is generally usable. The proportion of the code that talks to the kernel is quite small. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Hi Avi, On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity a...@redhat.com wrote: tools/power was merged in just 2 versions ago, do you think that merging that was a mistake? Things like tools/power may make sense, most of the code is tied to the kernel interfaces. tools/kvm is 20k lines and is likely to be 40k+ lines or more before it is generally usable. The proportion of the code that talks to the kernel is quite small. So what do you think about perf then? The amount of code that talks to the kernel is much smaller than that of the KVM tool. Pekka
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Hi Ted, On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o ty...@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 ty...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 07, 2011 at 02:29:45PM +0200, Pekka Enberg wrote: So what do you think about perf then? The amount of code that talks to the kernel is much smaller than that of the KVM tool. I think it's a mess, because it's never clear whether perf needs to be upgraded when I upgrade the kernel, or vice versa. This is why I keep harping on the interface issues. Fortunately it seems less likely (since perf doesn't run with privileges) that security fixes will need to be released for perf, but if it did, given the typical regression testing requirements that many distributions have, and given that most distro packaging tools assume that all binaries from a single source package come from a single version of that source package, I predict you will hear screams from the distro release engineers. And by the way, there are use cases, where the guest OS kernel and root on the guest OS are not available to the untrusted users, where the userspace KVM program would be part of the security perimeter, and were security releases to the KVM part of the tool might very well be necessary, and it would be unfortunate if that forced the release of new kernel packages each time security fixes are needed to the kvm-tool userspace. Might kvm-tool be more secure than qemu? Quite possibly, given that it's going to do less than qemu. But please note that I've not been arguing that kvm-tool shouldn't be done; just that it not be included in the kernel sources. Just as sparse is not bundled into the kernel sources, for crying out loud! - Ted
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/07/2011 02:29 PM, Pekka Enberg wrote: Hi Avi, On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity a...@redhat.com wrote: tools/power was merged in just 2 versions ago, do you think that merging that was a mistake? Things like tools/power may make sense, most of the code is tied to the kernel interfaces. tools/kvm is 20k lines and is likely to be 40k+ lines or more before it is generally usable. The proportion of the code that talks to the kernel is quite small. So what do you think about perf then? The amount of code that talks to the kernel is much smaller than that of the KVM tool. Maybe it's outgrown the kernel repo too. Certainly something that has perl and python integration, a TUI, and one day hopefully a GUI, doesn't really need the kernel sources. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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 ty...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/07/2011 05:57 AM, Ingo Molnar wrote: * Pekka Enbergpenb...@cs.helsinki.fi wrote: On Mon, 7 Nov 2011, Gerd Hoffmann wrote: It's not just about code, it's as much about culture and development process. Indeed. The BSDs have both kernel and the base system in a single repository. There are probably good reasons for (and against) it. In Linux we don't have that culture. No tool (except perf) lives in the kernel repo. I fail to see why kvm-tool is that much different from udev, util-linux, iproute, filesystem tools, that it should be included. You seem to think perf is an exception - I think it's going to be the future norm for userspace components that are very close to the kernel. That's in fact what Ingo was arguing for when he suggested QEMU to be merged to the kernel tree. Yep, and the answer i got from the Qemu folks when i suggested that merge was a polite buzz off, along the lines of: We don't want to do that, but feel free to write your own tool, leave Qemu alone. At least it was polite :-) Now that people have done exactly that some Qemu folks not only have changed their objection from write your own tool to erm, write your own tool but do it the way *we* prefer you to do it - they also started contributing *against* the KVM tool with predictable, once every 3 months objections against its upstream merge... That's not very nice and not very constructive. I think it's fair to have an objection to upstream merge but I think these threads are not terribly constructive right now as it's just rehashing the same arguments. I've been thinking about the idea of merging more userspace tools into the kernel. I understand the basic reasoning. The kernel has a strong, established development process. It has good infrastructure and a robust hierarchy of maintainers. Good infrastructure can make a big difference to the success of a project. Expanding the kernel infrastructure to more projects does seem like an obvious thing to do when you think about it in that way. The approach other projects have taken to this is to form a formal incubator. Apache is a good example of this. There are clear (written) rules about what it takes for a project to join. Once a project joins, there's a clear governance structure. The project gets to consume all of the Apache infrastructure resources. Other foundations have a release cadence to ensure that multiple components form a cohesive individual release (oVirt). I think you are trying to do this in a more organic way by just merging things into the main git tree. Have you thought about creating a more formal kernel incubator program? Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
I know kgdb can test kernel,but I haven't succeed . -- Original -- From: Pekka Enberg; Date: 2011年11月7日(星期一) 下午4:57 To: Paolo Bonzini; Cc: Alexander Graf; k...@vger.kernel.org list; qemu-devel Developers; linux-ker...@vger.kernel.org List; Blue Swirl; Avi Kivity; Américo Wan; Ingo Molnar; Linus Torvalds; Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels 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 pbonz...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, 7 Nov 2011, Pekka Enberg wrote: I've never heard ABI incompatibility used as an argument for perf. Ingo? Never overtly. They're too clever for that. In any case, as a primary developer of a library (PAPI) that uses the perf_events ABI I have to say that having perf in the kernel has been a *major* pain for us. Unlike the perf developers, we *do* have to maintain backwards compatability. And we have a lot of nasty code in PAPI to handle this. Entirely because the perf_events ABI is not stable. It's mostly stable, but there are enough regressions to be a pain. It's problem enough that there's no way to know what version of the perf_event abi you are running against and we have to guess based on kernel version. This gets fun because all of the vendors have backported seemingly random chunks of perf_event code to their older kernels. And it often does seem as the perf developers don't care when something breaks in perf_events if it doesn't affect perf users. For example, the new NMI watchdog severely breaks perf_event event allocation if you are using FORMAT_GROUP. perf doesn't use this though, so none of the kernel developers seem to care. And unless I can quickly come up with a patch as an outsider, a few kernel versions will go by and the kernel devs will declare well it was broken so long, now we don't have to fix it. Fun. Vince
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
* Vince Weaver vi...@deater.net wrote: On Mon, 7 Nov 2011, Pekka Enberg wrote: I've never heard ABI incompatibility used as an argument for perf. Ingo? Correct, the ABI has been designed in a way to make it really hard to break the ABI via either directed backports or other mess-ups. The ABI is both backwards *and* forwards ABI compatible, which is very rare amongst Linux ABIs. For frequently used tools, such as perf, there's no ABI compatibility problem in practice: using newer perf on older kernels is pretty common. Using older perf on new kernels is rarer, but that generally works too. In hindsight being in the kernel repo made it *easier* for perf to implement a good, stable ABI while also keeping a very high rate of change of the subsystem: changes are more 'concentrated' and people can stay focused on the ball to extend the ABI in sensible ways instead of struggling with project boundary artifacts. I think we needed to do only one revert along the way in the past two years, to fix an unintended ABI breakage in PowerTop. Considering the total complexity of the perf ABI our compatibility track record is *very* good. Never overtly. They're too clever for that. Pekka, Vince has meanwhile become the resident perf critic on lkml, always in it when it comes to some perf-bashing: In any case, as a primary developer of a library (PAPI) that uses the perf_events ABI I have to say that having perf in the kernel has been a *major* pain for us. ... and you have argued against perf from the very first day on, when you were one of the perfmon developers - and IMO in hindsight you've been repeatedly wrong about most of your design arguments. Unlike the perf developers, we *do* have to maintain backwards compatability. [...] We do too, i use new perf on older distro kernels all the time. If you see a breakage of functionality that tools use and report in a timely fashion then please report it. [...] And we have a lot of nasty code in PAPI to handle this. Entirely because the perf_events ABI is not stable. It's mostly stable, but there are enough regressions to be a pain. You are blaming the wrong guys really. The PAPI project has the (fundamental) problem that you are still doing it in the old-style sw design fashion, with many months long delays in testing, and then you are blaming the problems you inevitably meet with that model on *us*. There was one PAPI incident i remember where it took you several *months* to report a regression in a regular PAPI test-case (no actual app affected as far as i know). No other tester ever ran the PAPI testcases so nobody else reported it. Moving perf out of the kernel would make that particular situation *worse*, by further increasing the latency of fixes and by further increasing the risk of breakages. Sorry, but you are trying to fix perf by dragging it down to your bad level of design and we will understandably resist that ... It's problem enough that there's no way to know what version of the perf_event abi you are running against and we have to guess based on kernel version. This gets fun because all of the vendors have backported seemingly random chunks of perf_event code to their older kernels. The ABI design allows for that kind of flexible extensibility, and it's one of its major advantages. What we *cannot* protect against is you relying on obscure details of the ABI without adding it to 'perf test' and then not testing the upstream kernel in a timely enough fashion either ... Nobody but you tests PAPI so you need to become *part* of the upstream development process, which releases a new upstream kernel every 3 months. And it often does seem as the perf developers don't care when something breaks in perf_events if it doesn't affect perf users. I have to reject your slander, both Peter, Arnaldo and me care deeply about fixing regressions and i've personally applied fixes out of order that addressed some sort of PAPI problem - whenever you chose to report them. Vince, you are wrong and you have also become somewhat malicious in your arguments - please stop it. For example, the new NMI watchdog severely breaks perf_event event allocation if you are using FORMAT_GROUP. perf doesn't use this though, so none of the kernel developers seem to care. And unless I can quickly come up with a patch as an outsider, a few kernel versions will go by and the kernel devs will declare well it was broken so long, now we don't have to fix it. Fun. Face it, the *real* problem is that beyond yourself very few people who use a new kernel use PAPI and your long latency of testing exposes you to breakages in a much more agile subsystem such as perf. Please fix that instead of blaming it on others. Also, as i mentioned it several times before, you are free to add an arbitrary number of ABI test-cases to 'perf test' and we can promise that we run that. Right now it consists of a
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, 7 Nov 2011, Pekka Enberg wrote: I've never heard ABI incompatibility used as an argument for perf. Ingo? On Mon, Nov 7, 2011 at 7:03 PM, Vince Weaver vi...@deater.net wrote: Never overtly. They're too clever for that. If you want me to take you seriously, spare me from the conspiracy theories, OK? I'm sure perf developers break the ABI sometimes - that happens elsewhere in the kernel as well. However, Ted claimed that perf developers use tools/perf as an excuse to break the ABI _on purpose_ which is something I have hard time believing. Your snarky remarks doesn't really help this discussion either. It's apparent from the LKML discussions that you're more interested in arguing with the perf developers rather than helping them. Pekka
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Ingo Molnar mi...@elte.hu writes: [...] It's problem enough that there's no way to know what version of the perf_event abi you are running against and we have to guess based on kernel version. This gets fun because all of the vendors have backported seemingly random chunks of perf_event code to their older kernels. The ABI design allows for that kind of flexible extensibility, and it's one of its major advantages. What we *cannot* protect against is you relying on obscure details of the ABI [...] Is there some documentation that clearly spells out which parts of the perf syscall userspace ABI are obscure and thus presumably changeable? [...] The usual ABI rules also apply: we'll revert everything that breaks the ABI - but for that you need to report it *in time* [...] If the ABI is so great in its flexible extensibility, how come it can't be flexibly extended without having to passing the burden of compatibility testing reversion-yawping to someone else? - FChE
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, 7 Nov 2011, Frank Ch. Eigler wrote: The ABI design allows for that kind of flexible extensibility, and it's one of its major advantages. What we *cannot* protect against is you relying on obscure details of the ABI [...] Is there some documentation that clearly spells out which parts of the perf syscall userspace ABI are obscure and thus presumably changeable? That's actually something the KVM and virtio folks have done a great job with IMHO. Both ABIs are documented pretty extensively and the specs are kept up to date. I guess for perf ABI, perf test is the closest thing to a specification so if your application is using something that's not covered by it, you might be in trouble. Pekka
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 07, 2011 at 09:53:28PM +0200, Pekka Enberg wrote: I'm sure perf developers break the ABI sometimes - that happens elsewhere in the kernel as well. However, Ted claimed that perf developers use tools/perf as an excuse to break the ABI _on purpose_ which is something I have hard time believing. I remember an assertion, probably a year or two ago, probably at the previous year's kernel summit, that one of the reasons for having the perf code inline in the kernel was so that synchronized changes could be made to both the kernel and userspace tool together. So it's not a matter of breaking the ABI _on_ _purpose_, it's an assertion that there is no ABI at all. Since the perf tool and the kernel tool have to be built together, so long as a user does that, no harm, no foul. Recall that Linus has said that he doesn't care about whether or not something is an ABI; he only care if users code don't perceive breakage. If they didn't perceive breakage, then it doesn't matter if an interface is changed. So the real question is whether or not this was an excuse to break the ABI, but whether or not the perf developers acknowledge there is an ABI at all, and whether it's OK for other developers to depend on the syscall interface or not. Actually, though, it shouldn't matter, because intentions don't matter. Recall the powertop/ftrace case. If you expose an interface, and people start using that interface, then you can't break them, period. So as far as Vince is concerned, if you have a userspace library which depends on the perf interface, then you should try out the kernel after each merge window, and if your library breaks, you should complain to Ingo and Linus directly, and request that the commit which broke your tool to be reverted --- because that's the rule; no breakage is allowed. As far as kvm-tool being in the kernel, I still don't see particularly valid arguments for why it should be in the kernel. It can't be the perf argument of we can make simultaneous changes in the userspace and kernel code, because if those changes break qemu-kvm, then a complaint to Linus will cause the problem code to be reverted. As far as the code using the same coding conventions and naming conventions as the kernel, that to me isn't a particular strong argument either. E2fsprogs uses the Signed-off-by lines, and the same coding conventions of the kernel, and it even has a slightly modified version of two kernel source file in e2fsprogs (e2fsck/recovery.c and e2fsck/revoke.c), plus a header file with data structures that have to be kept in sync with the kernel header file. But that doesn't make it part of the kernel, and it's not a justification for it to be bundled with the kernel. Personally, I consider code that runs in userspace as a pretty bright line, as being not kernel code, and while perhaps things like initramfs and the crazy ideas people have had in the past of moving stuff out of kernel/init.c into userspace might have qualified as stuff really close to the kernel, something like kvm-tool that runs way after boot, doesn't even come close. Wine is another example of another package that has lots of close kernel ties, but was also not bundled into the kernel. The precedent has all mainly been on the keep the kernel separate side of things, and the arguments for bundling it with the kernel are much weaker, especially since the interface is well-developed, and there are external users of the interface which means you can't make changes to the interface willy-nilly. Indeed, when the perf interface was changing all the time, maybe there was some convenience to have it be bundled with the kernel, so there was no need to negotiate interface version numbers, et. al. But given how it has to link in so many user space libraries, I personally think it's fair to ask the question whether now that it has matured, whether it's time to move it out of the kernel source tree. Regards, - Ted
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 07, 2011 at 10:09:34PM +0200, Pekka Enberg wrote: I guess for perf ABI, perf test is the closest thing to a specification so if your application is using something that's not covered by it, you might be in trouble. I don't believe there's ever been any guarantee that perf test from version N of the kernel will always work on a version N+M of the kernel. Perhaps I am wrong, though. If that is a guarantee that the perf developers are willing to stand behind, or have already made, I would love to be corrected and would be delighted to hear that in fact there is a stable, backwards compatible perf ABI. Regards, - Ted
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Hi Ted, On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o ty...@mit.edu wrote: Personally, I consider code that runs in userspace as a pretty bright line, as being not kernel code, and while perhaps things like initramfs and the crazy ideas people have had in the past of moving stuff out of kernel/init.c into userspace might have qualified as stuff really close to the kernel, something like kvm-tool that runs way after boot, doesn't even come close. Wine is another example of another package that has lots of close kernel ties, but was also not bundled into the kernel. It's not as clear line as you make it out to be. KVM tool also has mini-BIOS code that runs in guest space. It has a code that runs in userspace but is effectively a simple bootloader. So it definitely doesn't fit the simple definition of running way after boot (we're _booting_ the kernel too). Linsched fits your definition but is clearly worth integrating to the kernel tree. While you are suggesting that maybe we should move Perf out of the tree now that it's mature, I'm pretty sure you'd agree that it probably would not have happened if the userspace parts were developed out of tree. There's also spectacular failures in the kernel history where the userspace split was enforced. For example, userspace suspend didn't turn out the way people envisioned it at the time. We don't know how it would have worked out if the userspace components would have been in the tree but it certainly would have solved many if the early ABI issues. I guess I'm trying to argue here that there's a middle ground. I'm willing to bet projects like klibc and unified initramfs will eventually make it to the kernel tree because they simply make so much sense. I'm also willing to be that the costs of moving Perf out of the tree are simply too high to make it worthwhile. Does that mean KVM tool should get a free pass in merging? Absolutely not. But I do think your position is too extreme and ignores the benefits of developing userspace tools in the kernel ecosystem which was summed up by Anthony rather well in this thread: https://lkml.org/lkml/2011/11/7/169 Pekka
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/07/2011 03:36 PM, Pekka Enberg wrote: Hi Ted, On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'oty...@mit.edu wrote: Personally, I consider code that runs in userspace as a pretty bright line, as being not kernel code, and while perhaps things like initramfs and the crazy ideas people have had in the past of moving stuff out of kernel/init.c into userspace might have qualified as stuff really close to the kernel, something like kvm-tool that runs way after boot, doesn't even come close. Wine is another example of another package that has lots of close kernel ties, but was also not bundled into the kernel. It's not as clear line as you make it out to be. KVM tool also has mini-BIOS code that runs in guest space. It has a code that runs in userspace but is effectively a simple bootloader. So it definitely doesn't fit the simple definition of running way after boot (we're _booting_ the kernel too). Linsched fits your definition but is clearly worth integrating to the kernel tree. While you are suggesting that maybe we should move Perf out of the tree now that it's mature, I'm pretty sure you'd agree that it probably would not have happened if the userspace parts were developed out of tree. There's also spectacular failures in the kernel history where the userspace split was enforced. For example, userspace suspend didn't turn out the way people envisioned it at the time. We don't know how it would have worked out if the userspace components would have been in the tree but it certainly would have solved many if the early ABI issues. I guess I'm trying to argue here that there's a middle ground. I'm willing to bet projects like klibc and unified initramfs will eventually make it to the kernel tree because they simply make so much sense. I'm also willing to be that the costs of moving Perf out of the tree are simply too high to make it worthwhile. Does that mean KVM tool should get a free pass in merging? Absolutely not. But I do think your position is too extreme and ignores the benefits of developing userspace tools in the kernel ecosystem which was summed up by Anthony rather well in this thread: https://lkml.org/lkml/2011/11/7/169 The kernel ecosystem does not have to be limited to linux.git. There could be a process to be a kernel.org project for projects that fit a certain set of criteria. These projects could all share the Linux kernel release cadence and have a kernel maintainer as a sponsor or something like that. That is something that could potentially benefit things like e2fs-tools and all of the other tools that are tied closely to the kernel. In fact, having a single place where users could find all of the various kernel related tools and helpers would probably be extremely useful. There's no reason this needs to be linux.git though, this could just be a web page on kernel.org. Regards, Anthony Liguori Pekka
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Nov 7, 2011, at 5:19 PM, Anthony Liguori wrote: The kernel ecosystem does not have to be limited to linux.git. There could be a process to be a kernel.org project for projects that fit a certain set of criteria. These projects could all share the Linux kernel release cadence and have a kernel maintainer as a sponsor or something like that. That is something that could potentially benefit things like e2fs-tools and all of the other tools that are tied closely to the kernel. We have that already. Packages such as e2fsprogs, xfsprogs, xfstests, sparse, git, etc., have git trees under git.kernel.org. And I agree that's the perfect place for kvm-tool and perf. :-) -- Ted
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, 7 Nov 2011, Ingo Molnar wrote: I think we needed to do only one revert along the way in the past two years, to fix an unintended ABI breakage in PowerTop. Considering the total complexity of the perf ABI our compatibility track record is *very* good. There have been more breakages, as you know. It's just they weren't caught in time so they were declared to be grandfathered in rather than fixed. Pekka, Vince has meanwhile become the resident perf critic on lkml, always in it when it comes to some perf-bashing: For what it's worth you'll find commits from me in the qemu tree, and I also oppose the merge of kvm-tool into the Linux tree. ... and you have argued against perf from the very first day on, when you were one of the perfmon developers - and IMO in hindsight you've been repeatedly wrong about most of your design arguments. I can't find an exact e-mail, but I seem to recall my arguments were that Pentium 4 support would be hard (it was), that in-kernel generalized events were a bad idea (I still think that, try talking to the ARM guys sometime about that) and that making access to raw events hard (by not using a naming library) was silly. I'm sure I probably said other things that were eventually addressed. The PAPI project has the (fundamental) problem that you are still doing it in the old-style sw design fashion, with many months long delays in testing, and then you are blaming the problems you inevitably meet with that model on *us*. The fundamental problem with the PAPI project is that we only have 3 full-time developers, and we have to make sure PAPI runs on about 10 different platforms, of which perf_events/Linux is only one. Time I waste tracking down perf_event ABI regressions and DoS bugs takes away from actual useful userspace PAPI development. There was one PAPI incident i remember where it took you several *months* to report a regression in a regular PAPI test-case (no actual app affected as far as i know). No other tester ever ran the PAPI testcases so nobody else reported it. We have a huge userbase. They run on some pretty amazing machines and do some tests that strain perf libraries to the limit. They also tend to use distro kernels, assuming they even have moved to 2.6.31+ kernels yet. When these power users report problems, they aren't going to be against the -tip tree. Nobody but you tests PAPI so you need to become *part* of the upstream development process, which releases a new upstream kernel every 3 months. PAPI is a free software project, with the devel tree available from CVS. It takes maybe 15 minutes to run the full PAPI regression suite. I encourage you or any perf developer to try it and report any issues. I can only be so comprehensive. I didn't find the current NMI-watchdog regression right away because my git tree builds didn't have it enabled. It wasn't until there started being 3.0 distro kernels that people started reporting the problem to us. Also, as i mentioned it several times before, you are free to add an arbitrary number of ABI test-cases to 'perf test' and we can promise that we run that. Right now it consists of a few tests: as mentioned before I have my own perf_event test suite with 20+ tests. http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html I do run it often. It tends to be reactionary though, as I can only add a test for a bug once I know about it. I also have more up-to date perf documentation than the kernel does: http://web.eecs.utk.edu/~vweaver1/projects/perf-events/programming.html and a cpu compatability matrix: http://web.eecs.utk.edu/~vweaver1/projects/perf-events/support.html I didn't really want to turn this into yet another perf flamewar. I just didn't want the implication that perf being in kernel is all rainbows and unicorns to go unchallenged. Vince
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Hi Alexander, On Sun, Nov 6, 2011 at 3:35 AM, Alexander Graf ag...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/06/2011 12:04 PM, Pekka Enberg wrote: Hi Alexander, On Sun, Nov 6, 2011 at 3:35 AM, Alexander Graf ag...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 12:07 PM, Avi Kivity a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/06/2011 12:12 PM, Pekka Enberg wrote: On Sun, Nov 6, 2011 at 12:07 PM, Avi Kivity a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/06/2011 02:14 PM, Pekka Enberg wrote: On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/06/2011 02:32 PM, Pekka Enberg wrote: On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@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 a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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 ag...@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 000..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)
+
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/06/2011 03:06 PM, Pekka Enberg wrote: On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@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 a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Hi Jan, On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Hi Avi, On Sun, Nov 6, 2011 at 5:56 PM, Avi Kivity a...@redhat.com wrote: On 11/06/2011 03:06 PM, Pekka Enberg wrote: On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@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 a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 2011-11-06 17:30, Pekka Enberg wrote: Hi Jan, On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@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 .config.bz2 Description: application/bzip signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/06/2011 10:50 AM, Avi Kivity wrote: On 11/06/2011 06:35 PM, Pekka Enberg wrote: The difference here is that although I feel Alex's script is a pointless project, I'm in no way opposed to merging it in the tree if people use it and it solves their problem. Some people seem to be violently opposed to merging the KVM tool and I'm having difficult time understanding why that is. One of the reasons is that if it is merge, anyone with a #include linux/foo.h will line up for the next merge window, wanting in. The other is that anything in the Linux source tree might gain an unfair advantage over out-of-tree projects (at least that's how I read Jan's comment). Well, having gone through the process of getting something included so far, I'm not at all worried that there's going to be a huge queue of #includelinux/foo.h projects if we get in... What kind of unfair advantage are you referring to? I've specifically said that the only way for KVM tool to become a reference implementation would be that the KVM maintainers take the tool through their tree. As that's not going to happen, I don't see what the problem would be. I'm not personally worried about it either (though in fact a *minimal* reference implementation might not be a bad idea). There's the risk of getting informed in-depth press reviews (Linux KVM Takes A Step Back From Running Windows Guests), or of unfairly drawing developers away from competing projects. I don't think that's really a concern. Competition is a good thing. QEMU is a large code base that a lot of people rely upon. It's hard to take big risks in a project like QEMU because the consequences are too high. OTOH, a project like KVM tool can take a lot of risks. They've attempted a very different command line syntax and they've put a lot of work into making virtio-9p a main part of the interface. If it turns out that these things end up working out well for them, then it becomes something we can copy in QEMU. If not, then we didn't go through the train wreck of totally changing CLI syntax only to find it was the wrong syntax. I'm quite happy with KVM tool and hope they continue working on it. My only real wish is that they wouldn't copy QEMU so much and would try bolder things that are fundamentally different from QEMU. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 06.11.2011, at 05:11, Pekka Enberg wrote: On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@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. That's a matter of taste. In fact, I like the QEMU source code for most parts and there was a whole talk around it on LinuxCon where people agreed that it was really easy to hack away with to prototype new hardware: https://events.linuxfoundation.org/events/linuxcon-europe/waskiewicz As for all matters concerning taste, I don't think we would ever get to a common ground here :). Alex
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/06/2011 07:06 AM, Pekka Enberg wrote: On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivitya...@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 Kivitya...@redhat.com wrote: You accept that qemu's scope is broader than kvm-tool (and is a superset). That is why many people think kvm-tool is pointless. Sure. I think it's mostly people that are interested in non-Linux virtualization that think the KVM tool is a pointless project. However, some people (including myself) think the KVM tool is a more usable and hackable tool than QEMU for Linux virtualization. There are literally dozens of mini operating systems that exist for exactly the same reason that you describe above. They are smaller and easier to hack on than something like Linux. Regards, Anthony Liguori The difference here is that although I feel Alex's script is a pointless project, I'm in no way opposed to merging it in the tree if people use it and it solves their problem. Some people seem to be violently opposed to merging the KVM tool and I'm having difficult time understanding why that is. Pekka
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 06.11.2011, at 05:06, Pekka Enberg wrote: On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@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 a...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf ag...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 06.11.2011, at 09:28, Pekka Enberg wrote: On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf ag...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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.
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 7:30 PM, Alexander Graf ag...@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 ag...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori anth...@codemonkey.ws wrote: I'm quite happy with KVM tool and hope they continue working on it. My only real wish is that they wouldn't copy QEMU so much and would try bolder things that are fundamentally different from QEMU. Hey, right now our only source of crazy ideas is Ingo and I think he's actually a pretty conservative guy when it comes to technology. Avi has expressed some crazy ideas in the past but they require switching away from C and that's not something we're interested in doing. ;-) Pekka
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote: I'm quite happy with KVM tool and hope they continue working on it. My only real wish is that they wouldn't copy QEMU so much and would try bolder things that are fundamentally different from QEMU. My big wish is that they don't try to merge the KVM tool into the kernel code. It's a separate userspace project, and there's no reason for it to be bundled with kernel code. It just makes the kernel sources larger. The mere fact that qemu-kvm exists means that the KVM interface has to remain backward compatible; it *is* an ABI. So integrating kvm-tool into the kernel isn't going to work as a free pass to make non-backwards compatible changes to the KVM user/kernel interface. Given that, why bloat the kernel source tree size? Please, keep the kvm-tool sources as a separate git tree. - Ted
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote: I'm quite happy with KVM tool and hope they continue working on it. My only real wish is that they wouldn't copy QEMU so much and would try bolder things that are fundamentally different from QEMU. On Sun, Nov 6, 2011 at 8:31 PM, Ted Ts'o ty...@mit.edu wrote: My big wish is that they don't try to merge the KVM tool into the kernel code. It's a separate userspace project, and there's no reason for it to be bundled with kernel code. It just makes the kernel sources larger. The mere fact that qemu-kvm exists means that the KVM interface has to remain backward compatible; it *is* an ABI. So integrating kvm-tool into the kernel isn't going to work as a free pass to make non-backwards compatible changes to the KVM user/kernel interface. Given that, why bloat the kernel source tree size? Ted, I'm confused. Making backwards incompatible ABI changes has never been on the table. Why are you bringing it up? Pekka
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 8:54 PM, Pekka Enberg penb...@kernel.org wrote: So integrating kvm-tool into the kernel isn't going to work as a free pass to make non-backwards compatible changes to the KVM user/kernel interface. Given that, why bloat the kernel source tree size? Ted, I'm confused. Making backwards incompatible ABI changes has never been on the table. Why are you bringing it up? And btw, KVM tool is not a random userspace project - it was designed to live in tools/kvm from the beginning. I've explained the technical rationale for sharing kernel code here: https://lkml.org/lkml/2011/11/4/150 Please also see Ingo's original rant that started the project: http://thread.gmane.org/gmane.linux.kernel/962051/focus=962620 Pekka
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On 11/06/2011 06:28 PM, Pekka Enberg wrote: On Sun, Nov 6, 2011 at 7:15 PM, Alexander Grafag...@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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 9:11 PM, Paolo Bonzini pbonz...@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?
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Sun, Nov 6, 2011 at 9:14 PM, Paolo Bonzini pbonz...@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.
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
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
