From patchwork Fri Mar 20 15:51:27 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bharata B Rao X-Patchwork-Id: 6057861 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 4D059BF90F for ; Fri, 20 Mar 2015 15:51:43 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 11D88204D5 for ; Fri, 20 Mar 2015 15:51:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 63A57203E6 for ; Fri, 20 Mar 2015 15:51:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752370AbbCTPvh (ORCPT ); Fri, 20 Mar 2015 11:51:37 -0400 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:50444 "EHLO e28smtp04.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751481AbbCTPvf (ORCPT ); Fri, 20 Mar 2015 11:51:35 -0400 Received: from /spool/local by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 20 Mar 2015 21:21:33 +0530 Received: from d28dlp03.in.ibm.com (9.184.220.128) by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 20 Mar 2015 21:21:30 +0530 Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id 4B560125804F; Fri, 20 Mar 2015 21:23:04 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay02.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2KFpT7Y26149068; Fri, 20 Mar 2015 21:21:30 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2KFkdFF017941; Fri, 20 Mar 2015 21:16:39 +0530 Received: from in.ibm.com ([9.124.214.157]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t2KFkbgq017824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Mar 2015 21:16:39 +0530 Date: Fri, 20 Mar 2015 21:21:27 +0530 From: Bharata B Rao To: Alexander Graf Cc: Paul Mackerras , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH 07/23] KVM: PPC: Book3S: Allow reuse of vCPU object Message-ID: <20150320155127.GA19984@in.ibm.com> Reply-To: bharata@linux.vnet.ibm.com References: <1426844400-12017-1-git-send-email-paulus@samba.org> <1426844400-12017-8-git-send-email-paulus@samba.org> <550BFE0C.2040006@suse.de> <20150320112650.GB9425@iris.ozlabs.ibm.com> <550C05BA.9020308@suse.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <550C05BA.9020308@suse.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15032015-0013-0000-0000-000004482D73 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Mar 20, 2015 at 12:34:18PM +0100, Alexander Graf wrote: > > > On 20.03.15 12:26, Paul Mackerras wrote: > > On Fri, Mar 20, 2015 at 12:01:32PM +0100, Alexander Graf wrote: > >> > >> > >> On 20.03.15 10:39, Paul Mackerras wrote: > >>> From: Bharata B Rao > >>> > >>> 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. > >>> > >>> More 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 > >>> > >>> In order to support this workaround with PowerPC KVM, don't create or > >>> initialize ICP if the vCPU is found to be already associated with an ICP. > >>> > >>> Signed-off-by: Bharata B Rao > >>> Signed-off-by: Paul Mackerras > >> > >> This probably makes some sense, but please make sure that user space has > >> some way to figure out whether hotplug works at all. > > > > Bharata is working on the qemu side of all this, so I assume he has > > that covered. > > Well, so far the kernel doesn't expose anything he can query, so I > suppose he just blindly assumes that older host kernels will randomly > break and nobody cares. I'd rather prefer to see a CAP exposed that qemu > can check on. I see that you have already taken this into your tree. I have an updated patch to expose a CAP. If the below patch looks ok, then let me know how you would prefer to take this patch in. Regards, Bharata. KVM: PPC: BOOK3S: Allow reuse of vCPU object From: Bharata B Rao 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. More 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 In order to support this workaround with PowerPC KVM, don't create or initialize ICP if the vCPU is found to be already associated with an ICP. User space (QEMU) can reuse the vCPU after checking for the availability of KVM_CAP_SPAPR_REUSE_VCPU capability. Signed-off-by: Bharata B Rao --- arch/powerpc/kvm/book3s_xics.c | 9 +++++++-- arch/powerpc/kvm/powerpc.c | 12 ++++++++++++ include/uapi/linux/kvm.h | 1 + 3 files changed, 20 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c index a4a8d9f..ead3a35 100644 --- a/arch/powerpc/kvm/book3s_xics.c +++ b/arch/powerpc/kvm/book3s_xics.c @@ -1313,8 +1313,13 @@ int kvmppc_xics_connect_vcpu(struct kvm_device *dev, struct kvm_vcpu *vcpu, return -EPERM; if (xics->kvm != vcpu->kvm) return -EPERM; - if (vcpu->arch.irq_type) - return -EBUSY; + + /* + * If irq_type is already set, don't reinialize but + * return success allowing this vcpu to be reused. + */ + if (vcpu->arch.irq_type != KVMPPC_IRQ_DEFAULT) + return 0; r = kvmppc_xics_create_icp(vcpu, xcpu); if (!r) diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index 27c0fac..5b7007c 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -564,6 +564,18 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) r = 1; break; #endif + case KVM_CAP_SPAPR_REUSE_VCPU: + /* + * Kernel currently doesn't support closing of vCPU fd from + * user space (QEMU) correctly. Hence the option available + * is to park the vCPU fd in user space whenever a guest + * CPU is hot removed and reuse the same later when another + * guest CPU is hotplugged. This capability determines whether + * it is safe to assume if parking of vCPU fd and reuse from + * user space works for sPAPR guests. + */ + r = 1; + break; default: r = 0; break; diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 8055706..8464755 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -760,6 +760,7 @@ struct kvm_ppc_smmu_info { #define KVM_CAP_PPC_ENABLE_HCALL 104 #define KVM_CAP_CHECK_EXTENSION_VM 105 #define KVM_CAP_S390_USER_SIGP 106 +#define KVM_CAP_SPAPR_REUSE_VCPU 107 #ifdef KVM_CAP_IRQ_ROUTING