From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IT5G7-0001ib-5I
	for qemu-devel@nongnu.org; Wed, 05 Sep 2007 20:30:11 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1IT5G6-0001hy-OA
	for qemu-devel@nongnu.org; Wed, 05 Sep 2007 20:30:10 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IT5G6-0001hr-Gi
	for qemu-devel@nongnu.org; Wed, 05 Sep 2007 20:30:10 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1IT5G6-0000aV-2T
	for qemu-devel@nongnu.org; Wed, 05 Sep 2007 20:30:10 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Re: [kvm-devel] expose host CPU features to guests
Date: Thu, 6 Sep 2007 01:30:02 +0100
References: <20070905174530.GA3945@karma.qumranet.com>
	<46DF04D5.5000807@qumranet.com> <20070905194448.GN5503@redhat.com>
In-Reply-To: <20070905194448.GN5503@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200709060130.03618.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
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: qemu-devel@nongnu.org, "Daniel P. Berrange" <berrange@redhat.com>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>

> > I think qemu-cvs has a -cpu option for non-x86 which could be used for
> > this.  Agree machine types are the wrong approach.
>
> Yep, machine types are already used to switch between a different concept
> so using  the new -cpu option would make sense. Could perhaps extend the
> syntax so that instead of '-cpu TYPE' it used '-cpu TYPE,FEATURES' where
> FEATURES was an optional list of CPU features to allow

I tried this for ARM, and having separate type+features isn't worth the 
effort. The internal implementation is feature based, but IMHO there's little 
benefit exposing that to the user. Just define appropriate CPUs for the 
interesting feature combinations.

Of course the x86 emulation doesn't currently support restricting the 
architecture features available.  To make the --cpu option useful you need to 
implement that first.

Paul