| Message ID | 1426844400-12017-8-git-send-email-paulus@samba.org |
|---|---|
| State | New, archived |
| Headers | show |
On 20.03.15 10:39, Paul Mackerras wrote: > From: Bharata B Rao <bharata@linux.vnet.ibm.com> > > 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 <bharata@linux.vnet.ibm.com> > Signed-off-by: Paul Mackerras <paulus@samba.org> This probably makes some sense, but please make sure that user space has some way to figure out whether hotplug works at all. Also Paul, for patches that you pick up from others, I'd prefer if they send the patches to the ML themselves first and you pick them up from there then. That way we give everyone the same treatment. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <bharata@linux.vnet.ibm.com> > > > > 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 <bharata@linux.vnet.ibm.com> > > Signed-off-by: Paul Mackerras <paulus@samba.org> > > 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. > Also Paul, for patches that you pick up from others, I'd prefer if they > send the patches to the ML themselves first and you pick them up from > there then. That way we give everyone the same treatment. Fair enough. In fact Bharata did post the patch but he sent it to linuxppc-dev@ozlabs.org not the KVM lists. Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <bharata@linux.vnet.ibm.com> >>> >>> 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 <bharata@linux.vnet.ibm.com> >>> Signed-off-by: Paul Mackerras <paulus@samba.org> >> >> 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. > >> Also Paul, for patches that you pick up from others, I'd prefer if they >> send the patches to the ML themselves first and you pick them up from >> there then. That way we give everyone the same treatment. > > Fair enough. In fact Bharata did post the patch but he sent it to > linuxppc-dev@ozlabs.org not the KVM lists. Please make sure you only take patches into your queue that made it to at least kvm@vger, preferably kvm-ppc@vger as well. If you see related patches on other mailing lists, just ask the respective people to resend with proper ML exposure. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" 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)