From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Gc0-00043k-O3 for qemu-devel@nongnu.org; Fri, 31 Jan 2014 11:06:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9Gbt-0008WQ-HQ for qemu-devel@nongnu.org; Fri, 31 Jan 2014 11:06:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Gbt-0008WE-85 for qemu-devel@nongnu.org; Fri, 31 Jan 2014 11:06:29 -0500 Date: Fri, 31 Jan 2014 17:06:21 +0100 From: Igor Mammedov Message-ID: <20140131170621.3857e584@thinkpad> In-Reply-To: <20140131151753.GY2221@otherpad.lan.raisama.net> References: <1391111339-6958-1-git-send-email-ehabkost@redhat.com> <20140131154853.34c41154@thinkpad> <52EBB82F.7020001@redhat.com> <20140131151753.GY2221@otherpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Cc: kvm@vger.kernel.org, libvir-list@redhat.com, qemu-devel@nongnu.org, Paolo Bonzini , Jiri Denemark , Andreas =?ISO-8859-1?B?RuRyYmVy?= On Fri, 31 Jan 2014 13:17:53 -0200 Eduardo Habkost wrote: > On Fri, Jan 31, 2014 at 03:50:23PM +0100, Paolo Bonzini wrote: > > Il 31/01/2014 15:48, Igor Mammedov ha scritto: > > >that's abusing of object-add interface and due to recent changes, object-add > > >won't accept arbitrary objects. > > > > I hope that sooner or later device hotplug will be doable with > > object-add too. But yes, in the meanwhile device_add could work, > > and this patch series is in the right direction anyway. > > In that case, what is holding us from setting > cannot_instantiate_with_device_add_yet on TYPE_X86_CPU? I don't think we > can recommend using "-device" for CPUs just yet, but we would need to > allow it in case object-add doesn't work. > > (But I liked the fact that object-add worked and (it looks like) it > didn't run realize(). All libvirt needs is to be able to create the > object and get instance_init() run, no need for realize() to run.) > > I still need to read the reasoning behind the object-add changes. But is > there some chance we could allow object-add to work for TYPE_X86_CPU > subclasses, to avoid the device_add/cannot_instantiate_with_device_add_yet issues? you can hack around by inheriting from UserCreatable interface, but question is what kind of information libvirt would expect from -object xxx-cpu if it's going to read/interpret feature words then CPU.instance_init() is not sufficient, since properties (read as compat props) and realize() itself are changing feature words and CPU model guest is going to see is very different from what -object would create. 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. > > -- > Eduardo -- Regards, Igor