From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH6rz-00077d-Go for qemu-devel@nongnu.org; Fri, 30 Jan 2015 03:24:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YH6rw-0004Ei-9h for qemu-devel@nongnu.org; Fri, 30 Jan 2015 03:24:03 -0500 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:46117) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH6rv-0004EI-LP for qemu-devel@nongnu.org; Fri, 30 Jan 2015 03:24:00 -0500 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 30 Jan 2015 13:53:56 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id D4CC11258059 for ; Fri, 30 Jan 2015 13:54:50 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay05.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t0U8Npoj66715836 for ; Fri, 30 Jan 2015 13:53:51 +0530 Received: from d28av02.in.ibm.com (localhost [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t0U8NoUf017866 for ; Fri, 30 Jan 2015 13:53:51 +0530 Date: Fri, 30 Jan 2015 13:53:47 +0530 From: Bharata B Rao Message-ID: <20150130082346.GF24041@in.ibm.com> References: <1420697420-16053-1-git-send-email-bharata@linux.vnet.ibm.com> <1420697420-16053-11-git-send-email-bharata@linux.vnet.ibm.com> <20150129014839.GT14681@voom> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150129014839.GT14681@voom> Subject: Re: [Qemu-devel] [RFC PATCH v1 10/13] cpus, spapr: reclaim allocated vCPU objects Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Gu Zheng , imammedo@redhat.com, agraf@suse.de, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com On Thu, Jan 29, 2015 at 12:48:39PM +1100, David Gibson wrote: > On Thu, Jan 08, 2015 at 11:40:17AM +0530, Bharata B Rao wrote: > > From: Gu Zheng > > This needs a commit message, it's not at all clear from the 1-line description. Borrowed patch, but I should have put in a description. > > diff --git a/kvm-all.c b/kvm-all.c > > index 18cc6b4..6f543ce 100644 > > --- a/kvm-all.c > > +++ b/kvm-all.c > > @@ -71,6 +71,12 @@ typedef struct KVMSlot > > > > typedef struct kvm_dirty_log KVMDirtyLog; > > > > +struct KVMParkedVcpu { > > + unsigned long vcpu_id; > > + int kvm_fd; > > + QLIST_ENTRY(KVMParkedVcpu) node; > > +}; > > + > > struct KVMState > > { > > AccelState parent_obj; > > @@ -107,6 +113,7 @@ struct KVMState > > QTAILQ_HEAD(msi_hashtab, KVMMSIRoute) msi_hashtab[KVM_MSI_HASHTAB_SIZE]; > > bool direct_msi; > > #endif > > + QLIST_HEAD(, KVMParkedVcpu) kvm_parked_vcpus; > > }; > > > > #define TYPE_KVM_ACCEL ACCEL_CLASS_NAME("kvm") > > @@ -247,6 +254,53 @@ static int kvm_set_user_memory_region(KVMState *s, KVMSlot *slot) > > return kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem); > > } > > > > +int kvm_destroy_vcpu(CPUState *cpu) > > +{ > > + KVMState *s = kvm_state; > > + long mmap_size; > > + struct KVMParkedVcpu *vcpu = NULL; > > + int ret = 0; > > + > > + DPRINTF("kvm_destroy_vcpu\n"); > > + > > + mmap_size = kvm_ioctl(s, KVM_GET_VCPU_MMAP_SIZE, 0); > > + if (mmap_size < 0) { > > + ret = mmap_size; > > + DPRINTF("kvm_destroy_vcpu failed\n"); > > + goto err; > > + } > > + > > + ret = munmap(cpu->kvm_run, mmap_size); > > + if (ret < 0) { > > + goto err; > > + } > > + > > + vcpu = g_malloc0(sizeof(*vcpu)); > > + vcpu->vcpu_id = kvm_arch_vcpu_id(cpu); > > + vcpu->kvm_fd = cpu->kvm_fd; > > + QLIST_INSERT_HEAD(&kvm_state->kvm_parked_vcpus, vcpu, node); > > What's the reason for parking vcpus rather than removing / recreating > them at the kvm level? Since KVM isn't equipped to handle closure of vcpu fd from userspace(QEMU) correctly, certain work arounds have to be employed to allow reuse of vcpu array slot in KVM during cpu hot plug/unplug from guest. One such proposed workaround is to park the vcpu fd in userspace during cpu unplug and reuse it later during next hotplug. Some details can be found here: KVM: https://www.mail-archive.com/kvm@vger.kernel.org/msg102839.html QEMU: http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00859.html Regards, Bharata.