From patchwork Mon May 8 12:49:32 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 9716171 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 152AD6035D for ; Mon, 8 May 2017 12:49:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 126FB1FF21 for ; Mon, 8 May 2017 12:49:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 067C322B39; Mon, 8 May 2017 12:49:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 881F21FF21 for ; Mon, 8 May 2017 12:49:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751388AbdEHMto (ORCPT ); Mon, 8 May 2017 08:49:44 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:37921 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750911AbdEHMtn (ORCPT ); Mon, 8 May 2017 08:49:43 -0400 Received: by mail-wm0-f53.google.com with SMTP id 142so63884376wma.1 for ; Mon, 08 May 2017 05:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=VOk9onnldEePDRqIWLs9nd4G+IPELo1CoYfTdpq51d4=; b=cg+1VTAvAhzzoqrMozu6A4h2+L2hglYFV4V0+1ko1QtThAa1sP/1EiFJjD+VAc50iK hFJEx24LZx1PT9uG+BzZcoiaZyafzg1RY0rinyUZBnPU54XoaAc8YKpB6k59ocUkfH8X CeeaumS1EFohamotO2gt4HKpMomCYLZBdSeAo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=VOk9onnldEePDRqIWLs9nd4G+IPELo1CoYfTdpq51d4=; b=Bp+qMd4clYBHT+256r/TNskovJDgJzD94n8ixmBe2KnWf+oIPsydBeJRjUFM7tIxIr SfPTLQTf8AKzuOFlvR2dL18P00SVTEVvei8KjIvameCEuYpz8fndDUu5n/5HQHHV6N05 SoxtDB3JKVGBksx/f+U+/wM8CaFyp1Gl1GXD55qq9b7JYFoCDpTqFtc1ndMP5WstWM5f OZLfgtaBgMRGp85yyhhGYkA7JRIdOOG7ayP2lJBeTC3GBswunA5XSlt3KQP1aUrq5mGT FrMliK14izzRo4MMoEiXHMIk6euXhEMDmPEID/YEDVfI735/PN52EG0U/0/sKF6KNDGx AcKw== X-Gm-Message-State: AN3rC/4tCIAtXWPYqJjRjL9yiXxKVmtWPHiUSY8WyKflP16dLOMGb4Kr arNI7KN4P+QtIEnR X-Received: by 10.80.178.131 with SMTP id p3mr43999014edd.96.1494247781872; Mon, 08 May 2017 05:49:41 -0700 (PDT) Received: from localhost.localdomain (xd93ddc2d.cust.hiper.dk. [217.61.220.45]) by smtp.gmail.com with ESMTPSA id j50sm4193577eda.44.2017.05.08.05.49.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 08 May 2017 05:49:41 -0700 (PDT) From: Christoffer Dall To: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Cc: kvm@vger.kernel.org, Marc Zyngier , Eric Auger , Christoffer Dall Subject: [PATCH 9/8] KVM: arm/arm64: Don't call map_resources when restoring ITS tables Date: Mon, 8 May 2017 14:49:32 +0200 Message-Id: <20170508124932.28399-1-cdall@linaro.org> X-Mailer: git-send-email 2.9.0 In-Reply-To: <20170508115454.5075-1-cdall@linaro.org> References: <20170508115454.5075-1-cdall@linaro.org> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The only reason we called kvm_vgic_map_resources() when restoring the ITS tables was because we wanted to have the KVM iodevs registered in the KVM IO bus framework at the time when the ITS was restored such that a restored and active device can inject MSIs prior to otherwise calling kvm_vgic_map_resources() from the first run of a VCPU. Since we now register the KVM iodevs for the redestributors and ITS as soon as possible (when setting the base addresses), we no longer need this call and kvm_vgic_map_resources() is again called only when first running a VCPU. Signed-off-by: Christoffer Dall Reviewed-by: Eric Auger --- Forgot to include this when posting the series, which was the whole point of the iodev rework in the first place. Apologies about the confusing 9/8 subject thing. virt/kvm/arm/vgic/vgic-its.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c index 00f2990..9b67621 100644 --- a/virt/kvm/arm/vgic/vgic-its.c +++ b/virt/kvm/arm/vgic/vgic-its.c @@ -2316,20 +2316,12 @@ static int vgic_its_restore_tables_v0(struct vgic_its *its) goto out; ret = vgic_its_restore_device_tables(its); - out: unlock_all_vcpus(kvm); mutex_unlock(&its->its_lock); mutex_unlock(&kvm->lock); - if (ret) - return ret; - - /* - * On restore path, MSI injections can happen before the - * first VCPU run so let's complete the GIC init here. - */ - return kvm_vgic_map_resources(its->dev->kvm); + return ret; } static int vgic_its_commit_v0(struct vgic_its *its)