From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaKjF-0001uE-81 for qemu-devel@nongnu.org; Tue, 24 Mar 2015 05:02:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaKjB-0000k2-78 for qemu-devel@nongnu.org; Tue, 24 Mar 2015 05:02:28 -0400 Received: from [59.151.112.132] (port=55220 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaKjA-0000jf-OG for qemu-devel@nongnu.org; Tue, 24 Mar 2015 05:02:25 -0400 Message-ID: <551127C0.6030909@cn.fujitsu.com> Date: Tue, 24 Mar 2015 17:00:48 +0800 From: Zhu Guihua MIME-Version: 1.0 References: <1423741993.32411.8.camel@G08FNSTD140041> <20150212161343.GG2024835@andariel.home> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [RFC PATCH v2 00/12] qemu: add support to hot-plug/unplug cpu device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhi Yong Wu , Peter Krempa Cc: libvir-list@redhat.com, qemu-devel@nongnu.org, isimatu.yasuaki@jp.fujitsu.com, guz.fnst@cn.fujitsu.com, imammedo@redhat.com, afaerber@suse.de On 03/24/2015 04:30 PM, Zhi Yong Wu wrote: > HI, > > Do you have plan to update this patchset based on the comments > recently or have the latest one to post? The develop plan for cpu hotplug in qemu has been changed, it is to add socket-based device_add. So I think we could not continue this cpu hotplug work in libvirt until the interface about this feature in qemu could be determined. Thanks, Zhu > > I noticed that the patchset for memory hotplug had got merged, is > there any plan to merge this patchset? > > > On Fri, Feb 13, 2015 at 12:13 AM, Peter Krempa wrote: >> On Thu, Feb 12, 2015 at 19:53:13 +0800, Zhu Guihua wrote: >>> Hi all, >>> >>> Any comments about this series? >>> >>> I'm not sure whether this series' method to support cpu hotplug in >>> libvirt is reasonable, so could anyone give more suggestions about this >>> function? Thanks. >> Well, as Dan pointed out in his review for this series and previous >> version, we are not convinced that we need a way to specify the CPU >> model and other parameters as having dissimilar CPUs doesn't make sense. >> >> A solution is either to build the cpu plug on top of the existing API or >> provide enough information to convince us that having the cpu model in >> the XML actually makes sense. >> >>> Regards, >>> Zhu >> Peter >> >> -- >> libvir-list mailing list >> libvir-list@redhat.com >> https://www.redhat.com/mailman/listinfo/libvir-list > >