From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E526C43218 for ; Fri, 26 Apr 2019 06:54:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1AD7B206DD for ; Fri, 26 Apr 2019 06:54:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ozlabs.org header.i=@ozlabs.org header.b="quPX+eUl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725947AbfDZGyV (ORCPT ); Fri, 26 Apr 2019 02:54:21 -0400 Received: from bilbo.ozlabs.org ([203.11.71.1]:38361 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725893AbfDZGyU (ORCPT ); Fri, 26 Apr 2019 02:54:20 -0400 Received: by ozlabs.org (Postfix, from userid 1003) id 44r4Xp3d6rz9s3l; Fri, 26 Apr 2019 16:54:18 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ozlabs.org; s=201707; t=1556261658; bh=EVe9nrxWRHRV9bpJcbPXTQO1KZrDvgGhyho3y/w29Cw=; h=Date:From:To:Cc:Subject:From; b=quPX+eUl6NRShq3LC3RKCG9rg8mwPdYILwDJYguiW8IJvV7szn8X5qFA6gFEUBZ91 cKiBBDxhCl8F/t1icohrC0bswZwhvCc+tMgW2Gn0Himttvh6i1lY9FfD8aVxTFjySI 0AKM3MPZBOgTtgr3SWPlJkhtM+6cifTtC7jS4/naXNN6s3JpnIJLrSHpLjT9saCKhT sQo9rWixCIn9ypQHMnNb3dc6/9iGlX+Idj4UBOMeyP/EVGs3efM7mL2H2vgY/vjGx1 A94vW2PNMs83WjbVYOaLznO6spZLq+9mYNHCICyScFDY+19HjD1Go5P6qygo4YJ4Qh WPSyRe1XyZD5A== Date: Fri, 26 Apr 2019 16:54:14 +1000 From: Paul Mackerras To: kvm@vger.kernel.org, =?iso-8859-1?Q?C=E9dric?= Le Goater Cc: David Gibson , kvm-ppc@vger.kernel.org Subject: [PATCH] KVM: PPC: Book3S HV: XIVE: Clear escalation interrupt pointers on device close Message-ID: <20190426065414.GC12768@blackberry> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org This adds code to ensure that after a XIVE or XICS-on-XIVE KVM device is closed, KVM will not try to enable or disable any of the escalation interrupts for the VCPUs. We don't have to worry about races between clearing the pointers and use of the pointers by the XIVE context push/pull code, because the callers hold the vcpu->mutex, which is also taken by the KVM_RUN code. Therefore the vcpu cannot be entering or exiting the guest concurrently. Signed-off-by: Paul Mackerras --- arch/powerpc/kvm/book3s_xive.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c index 4280cd8..4953957 100644 --- a/arch/powerpc/kvm/book3s_xive.c +++ b/arch/powerpc/kvm/book3s_xive.c @@ -1096,6 +1096,21 @@ void kvmppc_xive_disable_vcpu_interrupts(struct kvm_vcpu *vcpu) arch_spin_unlock(&sb->lock); } } + + /* Disable vcpu's escalation interrupt */ + if (vcpu->arch.xive_esc_on) { + __raw_readq((void __iomem *)(vcpu->arch.xive_esc_vaddr + + XIVE_ESB_SET_PQ_01)); + vcpu->arch.xive_esc_on = false; + } + + /* + * Clear pointers to escalation interrupt ESB. + * This is safe because the vcpu->mutex is held, preventing + * any other CPU from concurrently executing a KVM_RUN ioctl. + */ + vcpu->arch.xive_esc_vaddr = 0; + vcpu->arch.xive_esc_raddr = 0; } void kvmppc_xive_cleanup_vcpu(struct kvm_vcpu *vcpu) -- 2.7.4