From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7qLv-0003FW-Gu for qemu-devel@nongnu.org; Wed, 14 Mar 2012 11:43:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7qLo-0006Di-Py for qemu-devel@nongnu.org; Wed, 14 Mar 2012 11:43:03 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:42554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7qLo-0006DX-LS for qemu-devel@nongnu.org; Wed, 14 Mar 2012 11:42:56 -0400 Received: by yhoo21 with SMTP id o21so2226720yho.4 for ; Wed, 14 Mar 2012 08:42:55 -0700 (PDT) Message-ID: <4F60BC7A.9000504@codemonkey.ws> Date: Wed, 14 Mar 2012 10:42:50 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1329347774-23262-3-git-send-email-imammedo@redhat.com> <4F3CF010.1040607@siemens.com> <4F3CFBBB.5020600@codemonkey.ws> <4F5F141F.8080202@cn.fujitsu.com> <4F5F29CE.70806@suse.de> <4F604FF9.8010403@cn.fujitsu.com> <4F6058BE.4060403@redhat.com> <20120314134959.GC14227@dhcp-192-168-178-175.profitbricks.localdomain> <20120314152324.GF2304@redhat.com> <4F60BA15.90506@codemonkey.ws> <20120314153529.GG2304@redhat.com> In-Reply-To: <20120314153529.GG2304@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/7] Convert pc cpu to qdev List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Lai Jiangshan , Jan Kiszka , "qemu-devel@nongnu.org" , Vasilis Liaskovitis , Igor Mammedov , =?ISO-8859-1?Q?Andreas_F=E4rber?= On 03/14/2012 10:35 AM, Gleb Natapov wrote: > On Wed, Mar 14, 2012 at 10:32:37AM -0500, Anthony Liguori wrote: >> On 03/14/2012 10:23 AM, Gleb Natapov wrote: >>> On Wed, Mar 14, 2012 at 02:49:59PM +0100, Vasilis Liaskovitis wrote: >>>> Hi, >>>> >>>> On Wed, Mar 14, 2012 at 09:37:18AM +0100, Igor Mammedov wrote: >>>>> On 03/14/2012 08:59 AM, Lai Jiangshan wrote: >>>>>> not accepted, so I don't know how to take part in. >>>>> >>>>> As I see it, there is not much to do from cpu hot-plug perspective. >>>>> It's just a matter of adaptation QOM-ified cpus for usage from >>>>> qdev device_add, and I'm working on it. >>>>> However, there is a lot to be done in cpu unplug area: >>>>> - host side: there is unaccepted patches to destroy vcpu >>>>> during VM-lifecycle. They are still need to be worked on: >>>>> "[Qemu-devel] [PATCH 0] A series patches for kvm&qemu to enable vcpu destruction in kvm" >>>>> - linux guest side: kernel can receive ACPI request to unplug cpu, >>>>> but does nothing with it (last time I've tested it with 3.2 kernel), >>>>> You might wish to look at following mail threads: >>>>> https://lkml.org/lkml/2011/9/30/18 >>>>> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02254.html >>>> >>>> I also plan to resubmit the qemu-side of ACPI cpu unplug request: >>>> http://lists.nongnu.org/archive/html/qemu-devel/2012-01/msg03037.html >>>> so that they work independently of the "host side" patches mentioned above. >>>> >>>> It would be great for the QOMify/hotplug/icc patches to be accepted soon, >>>> since this would make unplug testing/development more straightoward. >>>> >>> On a different note, are your going to continue working on your memory hot plug series? >>> I am going to look at it now. >> >> Memory hotplug.. that's going to be fun :-) >> > Why? What fundamental difficultly do you anticipate? There's still a few places in QEMU that assume that qemu_ram_get_ptr() returns a pointer that's good indefinitely. We also don't have a mechanism to revoke cpu_physical_map() pointers. Maybe the answer is reference counting and relying on being able to eventually release the memory... Of course, then an unplug followed by an immediate plug would be complicated. Hot add should be easy, hot remove will be pretty hard I think. Regards, Anthony Liguori > > -- > Gleb.