linux-kernel - Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOJsxLF6bOPJk+atASGr_Ra3BfwbkGPfGb2iRCOrfpFODBc-jA@mail.gmail.com>
Date:	Sun, 6 Nov 2011 22:17:47 +0200
From:	Pekka Enberg <penberg@...nel.org>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Alexander Graf <agraf@...e.de>,
	"kvm@...r.kernel.org list" <kvm@...r.kernel.org>,
	qemu-devel Developers <qemu-devel@...gnu.org>,
	"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
	Blue Swirl <blauwirbel@...il.com>, Avi Kivity <avi@...hat.com>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels

On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>> If you're bisecting breakage that can be in the guest kernel or the
>> KVM tool, you'd want to build both.
>
> No.  I want to try new tool/old kernel and old tool/new kernel (kernel can
> be either guest or host, depending on the nature of the bug), and then
> bisect just one.  (*) And that's the exceptional case, and only KVM tool
> developers really should have the need to do that.

Exactly - having the source code in Linux kernel tree covers the
"exceptional case" where we're unsure which part of the equation broke
things (which are btw the nasties issues we've had so far). I have no
idea why you're trying to convince me that it doesn't matter. You can
bisect only one of the components in isolation just fine.

On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>> What would prevent you from using a newer KVM tool with an older kernel?
>
> Nothing, but I'm just giving you *strong* hints that a submodule or a merged
> tool is the wrong solution, and the histories of kernel and tool should be
> kept separate.
>
> More clearly: for its supposedly intended usage, namely testing development
> kernels in a *guest*, KVM tool will generally not run on the exact *host*
> kernel that is in the tree it lives with.  Almost never, in fact.  Unlike
> perf, if you want to test multiple guest kernels you should never need to
> rebuild KVM tool!
>
> This is the main argument as to whether or not to merge the tool.  Would the
> integration of the *build* make sense or not?  Assume you adapt the ktest
> script to make both the KVM tool and the kernel, and test the latter using
> the former.  Your host kernel never changes, and yet you introduce a new
> variable in your testing.  That complicates things, it doesn't simplify
> them.

I don't understand what trying to say. There's no requirement to build
the KVM tool if you're bisecting a guest kernel.

                        Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/