From patchwork Sat Mar 18 12:56:56 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 9632167 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 3385660249 for ; Sat, 18 Mar 2017 12:58:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 259A92833C for ; Sat, 18 Mar 2017 12:58:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 16B4C284FA; Sat, 18 Mar 2017 12:58:36 +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=unavailable 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 961742833C for ; Sat, 18 Mar 2017 12:58:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751341AbdCRM5z (ORCPT ); Sat, 18 Mar 2017 08:57:55 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:34100 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751025AbdCRM5y (ORCPT ); Sat, 18 Mar 2017 08:57:54 -0400 Received: by mail-wm0-f51.google.com with SMTP id 196so12390326wmm.1 for ; Sat, 18 Mar 2017 05:57:13 -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; bh=gWCtTXdWsRVDtFvrB05zQ3SeDTAVnf7Dbbu2UXfXdlI=; b=MYe65i0C8v94eWxGI9phoQcAnc5CvLm+/um4iU733vxyquxb+F5iIxTJk7/1fFpgTs sHrA+uZ6wvJMOhRO6l3v8ZKtrhnz7hK74EWHDUsHIcLTD4oYe7LrT0YxrMU5qz9EL3VX +o2+/OMxalRbGtb4SdX+xRRL2Vzl1WxH8y8x8= 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; bh=gWCtTXdWsRVDtFvrB05zQ3SeDTAVnf7Dbbu2UXfXdlI=; b=K5WxTiaJYZrfBYOdZTJawCBa67yJgxDXJYfBYUesdUptSH4nzNf3F98xyDBTWn1+tt lB0eu+fc63ZxcGJ7GS3S9Wqkga+Wb7ZwlfEKKL5EhmomPKeOE9NUSWML1fOCCctvk2X9 HOru1QfZvR+jJ0S/qd2ocz9jv6mrlJxXSA/dfgpoDsM2FCN7LsQmrvIsmgW0ibVTBUxJ yZ/p96BUmbJC0VEwRijHYgEorS0B/LbCkpW1gM0AVcT+hxnV6V4KYgDua+S+QsngT712 m+8kPm+XAo8nytKpY46tOlA7HmAII4KmLJzgDvCm8Y5ygpcrhvg5ryivyndZCpKFNNom xlBQ== X-Gm-Message-State: AFeK/H0ZNYfa+65rLVzZoen5cLbVVR7ZwF6rnfCL/87p6fJsZ+0vu9SrrGxbm0k5PLTP87Tc X-Received: by 10.28.218.197 with SMTP id r188mr533167wmg.0.1489841832122; Sat, 18 Mar 2017 05:57:12 -0700 (PDT) Received: from localhost.localdomain (xd93ddc2d.cust.hiper.dk. [217.61.220.45]) by smtp.gmail.com with ESMTPSA id g18sm6213062wme.2.2017.03.18.05.57.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 18 Mar 2017 05:57:11 -0700 (PDT) From: Christoffer Dall To: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Cc: kvm@vger.kernel.org, Marc Zyngier , Andre Przywara , Eric Auger , Christoffer Dall Subject: [PATCH] KVM: arm64: Ensure LRs are clear when they should be Date: Sat, 18 Mar 2017 13:56:56 +0100 Message-Id: <20170318125656.16523-1-cdall@linaro.org> X-Mailer: git-send-email 2.9.0 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Christoffer Dall We currently have some code to clear the list registers on GICv3, but we never call this code, because the caller got nuked when removing the old vgic. We also used to have a similar GICv2 part, but that got lost in the process too. Let's reintroduce the logic for GICv2 and call the logic when we initialize the use of hypervisors on the CPU, for example when first loading KVM or when exiting a low power state. Signed-off-by: Christoffer Dall Reviewed-by: Marc Zyngier --- Marc, Eric, Andre, I'm unable to convince myself that the LRs should already be clear via the reset of the hardware, and for any power management scenario I suppose it's possible for secure-side firmware to have messed with the LRs behind our backs; plus we used to have this functionality and it got dropped for the new vgic. Am I forgetting some discussion where we decided it wasn't needed anymore? Thanks, -Christoffer arch/arm/kvm/arm.c | 3 +++ include/kvm/arm_vgic.h | 1 + virt/kvm/arm/vgic/vgic-init.c | 19 +++++++++++++++++++ virt/kvm/arm/vgic/vgic-v2.c | 15 +++++++++++++++ virt/kvm/arm/vgic/vgic.h | 2 ++ 5 files changed, 40 insertions(+) diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c index c9a2103..d775aac 100644 --- a/arch/arm/kvm/arm.c +++ b/arch/arm/kvm/arm.c @@ -1121,6 +1121,9 @@ static void cpu_hyp_reinit(void) if (__hyp_get_vectors() == hyp_default_vectors) cpu_init_hyp_mode(NULL); } + + if (vgic_present) + kvm_vgic_init_cpu_hardware(); } static void cpu_hyp_reset(void) diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h index b72dd2a..c0b3d99 100644 --- a/include/kvm/arm_vgic.h +++ b/include/kvm/arm_vgic.h @@ -295,6 +295,7 @@ void kvm_vgic_vcpu_early_init(struct kvm_vcpu *vcpu); void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu); int kvm_vgic_map_resources(struct kvm *kvm); int kvm_vgic_hyp_init(void); +void kvm_vgic_init_cpu_hardware(void); int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int intid, bool level); diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c index 276139a..702f810 100644 --- a/virt/kvm/arm/vgic/vgic-init.c +++ b/virt/kvm/arm/vgic/vgic-init.c @@ -392,6 +392,25 @@ static irqreturn_t vgic_maintenance_handler(int irq, void *data) } /** + * kvm_vgic_init_cpu_hardware - initialize the GIC VE hardware + * + * For a specific CPU, initialize the GIC VE hardware. + */ +void kvm_vgic_init_cpu_hardware(void) +{ + BUG_ON(preemptible()); + + /* + * We want to make sure the list registers start out clear so that we + * only have the program the used registers. + */ + if (kvm_vgic_global_state.type == VGIC_V2) + vgic_v2_init_lrs(); + else + kvm_call_hyp(__vgic_v3_init_lrs); +} + +/** * kvm_vgic_hyp_init: populates the kvm_vgic_global_state variable * according to the host GIC model. Accordingly calls either * vgic_v2/v3_probe which registers the KVM_DEVICE that can be diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c index b834ecd..94cf4b9 100644 --- a/virt/kvm/arm/vgic/vgic-v2.c +++ b/virt/kvm/arm/vgic/vgic-v2.c @@ -36,6 +36,21 @@ static unsigned long *u64_to_bitmask(u64 *val) return (unsigned long *)val; } +static inline void vgic_v2_write_lr(int lr, u32 val) +{ + void __iomem *base = kvm_vgic_global_state.vctrl_base; + + writel_relaxed(val, base + GICH_LR0 + (lr * 4)); +} + +void vgic_v2_init_lrs(void) +{ + int i; + + for (i = 0; i < kvm_vgic_global_state.nr_lr; i++) + vgic_v2_write_lr(i, 0); +} + void vgic_v2_process_maintenance(struct kvm_vcpu *vcpu) { struct vgic_v2_cpu_if *cpuif = &vcpu->arch.vgic_cpu.vgic_v2; diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h index db28f7c..91566f5 100644 --- a/virt/kvm/arm/vgic/vgic.h +++ b/virt/kvm/arm/vgic/vgic.h @@ -130,6 +130,8 @@ int vgic_v2_map_resources(struct kvm *kvm); int vgic_register_dist_iodev(struct kvm *kvm, gpa_t dist_base_address, enum vgic_type); +void vgic_v2_init_lrs(void); + static inline void vgic_get_irq_kref(struct vgic_irq *irq) { if (irq->intid < VGIC_MIN_LPI)