From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:45293)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jdenemar@redhat.com>) id 1RbDH3-0000EC-NY
	for qemu-devel@nongnu.org; Thu, 15 Dec 2011 10:31:15 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jdenemar@redhat.com>) id 1RbDGv-0006rg-Av
	for qemu-devel@nongnu.org; Thu, 15 Dec 2011 10:31:09 -0500
Received: from mx1.redhat.com ([209.132.183.28]:57866)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jdenemar@redhat.com>) id 1RbDGu-0006rP-Uh
	for qemu-devel@nongnu.org; Thu, 15 Dec 2011 10:31:01 -0500
Date: Thu, 15 Dec 2011 16:30:52 +0100
From: Jiri Denemark <jdenemar@redhat.com>
Message-ID: <20111215153052.GC4584@orkuz.home>
References: <20111215145415.GA265695@orkuz.home>
	<4EEA0B2F.9010402@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EEA0B2F.9010402@codemonkey.ws>
Subject: Re: [Qemu-devel] Modern CPU models cannot be used with libvirt
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: libvir-list@redhat.com, qemu-devel@nongnu.org

On Thu, Dec 15, 2011 at 08:58:55 -0600, Anthony Liguori wrote:
> Pass '-readconfig /etc/qemu/target-x86_64.conf' to pick up those models and if 
> you are absolutely insistent on not giving the user any ability to change things 
> on their own, cp the file from qemu.git into libvirt.git and install it in a 
> safe place.

Ah, this looks like a good idea (and we could even generate that file
dynamically if we add support for family/stepping/... and other things that we
do not model now). However, separating these definitions from qemu may result
in incompatibilities with older qemu versions. I guess mainly because our
configuration file would mention a CPU feature that an installed qemu version
doesn't understand. Currently, qemu seems to just ignore such feature
(although it prints an error) and continues happily without it. Is there
any way for us to ask qemu what CPU features it knows about so that we could
avoid using a CPU models which include features qemu doesn't understand?

Jirka