From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9HL4-0004lU-CT for qemu-devel@nongnu.org; Fri, 31 Jan 2014 11:53:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9HKy-0007cv-DW for qemu-devel@nongnu.org; Fri, 31 Jan 2014 11:53:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9HKy-0007cn-5T for qemu-devel@nongnu.org; Fri, 31 Jan 2014 11:53:04 -0500 Message-ID: <52EBD4E9.2000700@redhat.com> Date: Fri, 31 Jan 2014 17:52:57 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1391111339-6958-1-git-send-email-ehabkost@redhat.com> <20140131154853.34c41154@thinkpad> <52EBB82F.7020001@redhat.com> <20140131151753.GY2221@otherpad.lan.raisama.net> <20140131170621.3857e584@thinkpad> <20140131164207.GZ2221@otherpad.lan.raisama.net> In-Reply-To: <20140131164207.GZ2221@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Igor Mammedov Cc: libvir-list@redhat.com, Jiri Denemark , qemu-devel@nongnu.org, kvm@vger.kernel.org, =?ISO-8859-1?Q?Andreas_F=E4rber?= Il 31/01/2014 17:42, Eduardo Habkost ha scritto: >> > It looks like only -device would be able to create actual CPU models, >> > but for -device to work we need as minimum this series and conversion >> > of CPU features to properties in tree. Then I guess we can override >> > cannot_instantiate_with_device_add_yet for x86 CPUs. > Setting cannot_instantiate_with_device_add_yet=false looks much simpler > than implementing UserCreatable. My question is: may we do that, already > (once this series gets included), or is there something else holding us > from doing it? Once you make something creatable with "-object", the API must not change anymore. So we would have to think twice about that. Allowing -device may be okay, since in the (very?) long term -device can be replaced by -object. But -object is definitive. Paolo