From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MOVDF-0004g1-Ut
	for qemu-devel@nongnu.org; Wed, 08 Jul 2009 07:21:22 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MOVDB-0004ff-Jt
	for qemu-devel@nongnu.org; Wed, 08 Jul 2009 07:21:21 -0400
Received: from [199.232.76.173] (port=42591 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MOVDB-0004fc-DU
	for qemu-devel@nongnu.org; Wed, 08 Jul 2009 07:21:17 -0400
Received: from verein.lst.de ([213.95.11.210]:45102)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1MOVDA-00059w-T7
	for qemu-devel@nongnu.org; Wed, 08 Jul 2009 07:21:17 -0400
Date: Wed, 8 Jul 2009 13:21:14 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH] qemu-iotests: look for qemu-iotests-$ARCH
Message-ID: <20090708112114.GA15008@lst.de>
References: <20090707180346.GA6233@lst.de> <4A545A1B.1080606@redhat.com>
	<20090708105915.GA14142@lst.de> <4A547E5A.7050404@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A547E5A.7050404@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org

On Wed, Jul 08, 2009 at 01:09:14PM +0200, Kevin Wolf wrote:
> I'm not sure that the KVM point of view really matters here. I can see
> two possible use cases for qemu: Either we just start it up without a
> guest OS to do things like a simple savevm, then TCG is just as good. Or
> we boot up a guest OS, then we obviously need the architecture matching
> the guest, not the host.

Right now we don't use any guest so that it doesn't really matter.  If
we actually end up running a guest we should agree on an architecture,
and also boundle the require guest (which would have to be a really
minimal one) in the qemu-iotests repository.  But for now I'd just avoid
requiring any guests.

> Maybe something like trying qemu-system-x86_64, then qemu-kvm, then
> qemu? We could use i386 guests on every host then. If it's accelerated
> with KVM, kqemu or not at all doesn't really matter.

Ok, fine with me.  I'll respin the patch.