Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1670696pxb; Wed, 9 Feb 2022 01:46:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJwUu5buMlJtxyRo2+JKMPrW040HL3w83hWU4LqM/kzLgw5rQMlWvDHxJ4HdkI7JrV6Uy1C1 X-Received: by 2002:a17:902:900b:: with SMTP id a11mr1286675plp.13.1644399973807; Wed, 09 Feb 2022 01:46:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644399973; cv=none; d=google.com; s=arc-20160816; b=W+yk0n9SdW0iO8WwlNvYcSq5e5ecaaN+kyz5nJkUdKlnntfaPyrQLj4ZFzacWc40uv bbpArjO6IuB/iHzxO30UJA4M4/ThGMyDA0p7MHEyHEYFkeqsecoxiTsWjDrktDl/QuWd +kdmYU+i7O3iYVwyK8fAVrR5aj0Bi22K16gDj1vq6+l8b9Zetcs1Usgl8oHiek8Y4xkn ce+8S80CikuEd3BLOfMoFMiY3LV4eSK53Qwd1zMxcsygX8Qqdgir8Woong2tWn6Hwphq o1zcUXSfHfxGWO60rRyhfxvJ9qiNnDfdb44RL2QH3LhaVJPMAj8BoUsnFvyq1r0u2m6Y AppA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Z6rDXuvZ/CttF9cRlsRKg8FMwFpDvE+3x4oBXaVTRDA=; b=izGZFSWBccwgMRJuQN4CVEO5QG8NTphaBik2MTRa4NEH+XBB/ixKYOkq4aRiZLFSwU 8BPvXhuR8XL48Hsdx96Lvv5IGsR7GIyzuwI+mHx0/tAdX9iKqjTbhD+R1dIc8FiSUTNC OIYptafM0S/G/oc1CzDAfliNqTINXpRLI4fXx+29/uzNI4KJSiXDuYQvUfKpWFsOjtn3 nM0yPqAXPAwYekMXyB0+BtABQrZScqJHeDgz2QL+739pJ20ehCLZ/+zY0RpWgkVNVIdk t+u864iE2sMFXnDlkRxqERSjNKhg3Srf8meHEC+qCZHC10flbKrutVl7qHeVlXxq1mGM eJ3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qX054NAr; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id f130si15899969pgc.684.2022.02.09.01.46.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 01:46:13 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qX054NAr; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 27364E06CD08; Wed, 9 Feb 2022 01:07:01 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234254AbiBGL6z (ORCPT + 99 others); Mon, 7 Feb 2022 06:58:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378601AbiBGLf4 (ORCPT ); Mon, 7 Feb 2022 06:35:56 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4EE4CC0401C2; Mon, 7 Feb 2022 03:35:48 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id DA6E6B8112C; Mon, 7 Feb 2022 11:35:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9BD2C004E1; Mon, 7 Feb 2022 11:35:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1644233745; bh=L7Ua2JQNOCa06ZsUU44srCbAmLOJXVGTcK1MykbM4Rw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qX054NArC84lEl8xczT06RMS/Ueu2VsOaLpocVYuVmGADv40cFoTtH3oacPD3JPd2 O+2q1oprRVPF15q4rrTD5WGaMhgNBI3k/ixAQfqJyyObszTMGci4E3hfsYEX/3kgFX PtZnoryfH+LdH9rQzdJzDI3aWr/SgPu5JNIjZSPU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolas Saenz Julienne , Mark Rutland , Marc Zyngier , Alexandru Elisei , Catalin Marinas , Frederic Weisbecker , James Morse , Paolo Bonzini , "Paul E. McKenney" , Suzuki K Poulose , Will Deacon , Sasha Levin Subject: [PATCH 5.16 108/126] kvm/arm64: rework guest entry logic Date: Mon, 7 Feb 2022 12:07:19 +0100 Message-Id: <20220207103807.791632381@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220207103804.053675072@linuxfoundation.org> References: <20220207103804.053675072@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mark Rutland [ Upstream commit 8cfe148a7136bc60452a5c6b7ac2d9d15c36909b ] In kvm_arch_vcpu_ioctl_run() we enter an RCU extended quiescent state (EQS) by calling guest_enter_irqoff(), and unmasked IRQs prior to exiting the EQS by calling guest_exit(). As the IRQ entry code will not wake RCU in this case, we may run the core IRQ code and IRQ handler without RCU watching, leading to various potential problems. Additionally, we do not inform lockdep or tracing that interrupts will be enabled during guest execution, which caan lead to misleading traces and warnings that interrupts have been enabled for overly-long periods. This patch fixes these issues by using the new timing and context entry/exit helpers to ensure that interrupts are handled during guest vtime but with RCU watching, with a sequence: guest_timing_enter_irqoff(); guest_state_enter_irqoff(); < run the vcpu > guest_state_exit_irqoff(); < take any pending IRQs > guest_timing_exit_irqoff(); Since instrumentation may make use of RCU, we must also ensure that no instrumented code is run during the EQS. I've split out the critical section into a new kvm_arm_enter_exit_vcpu() helper which is marked noinstr. Fixes: 1b3d546daf85ed2b ("arm/arm64: KVM: Properly account for guest CPU time") Reported-by: Nicolas Saenz Julienne Signed-off-by: Mark Rutland Reviewed-by: Marc Zyngier Reviewed-by: Nicolas Saenz Julienne Cc: Alexandru Elisei Cc: Catalin Marinas Cc: Frederic Weisbecker Cc: James Morse Cc: Paolo Bonzini Cc: Paul E. McKenney Cc: Suzuki K Poulose Cc: Will Deacon Message-Id: <20220201132926.3301912-3-mark.rutland@arm.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin --- arch/arm64/kvm/arm.c | 51 ++++++++++++++++++++++++++++---------------- 1 file changed, 33 insertions(+), 18 deletions(-) diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index e4727dc771bf3..b2222d8eb0b55 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -764,6 +764,24 @@ static bool kvm_vcpu_exit_request(struct kvm_vcpu *vcpu, int *ret) xfer_to_guest_mode_work_pending(); } +/* + * Actually run the vCPU, entering an RCU extended quiescent state (EQS) while + * the vCPU is running. + * + * This must be noinstr as instrumentation may make use of RCU, and this is not + * safe during the EQS. + */ +static int noinstr kvm_arm_vcpu_enter_exit(struct kvm_vcpu *vcpu) +{ + int ret; + + guest_state_enter_irqoff(); + ret = kvm_call_hyp_ret(__kvm_vcpu_run, vcpu); + guest_state_exit_irqoff(); + + return ret; +} + /** * kvm_arch_vcpu_ioctl_run - the main VCPU run function to execute guest code * @vcpu: The VCPU pointer @@ -854,9 +872,9 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) * Enter the guest */ trace_kvm_entry(*vcpu_pc(vcpu)); - guest_enter_irqoff(); + guest_timing_enter_irqoff(); - ret = kvm_call_hyp_ret(__kvm_vcpu_run, vcpu); + ret = kvm_arm_vcpu_enter_exit(vcpu); vcpu->mode = OUTSIDE_GUEST_MODE; vcpu->stat.exits++; @@ -891,26 +909,23 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) kvm_arch_vcpu_ctxsync_fp(vcpu); /* - * We may have taken a host interrupt in HYP mode (ie - * while executing the guest). This interrupt is still - * pending, as we haven't serviced it yet! + * We must ensure that any pending interrupts are taken before + * we exit guest timing so that timer ticks are accounted as + * guest time. Transiently unmask interrupts so that any + * pending interrupts are taken. * - * We're now back in SVC mode, with interrupts - * disabled. Enabling the interrupts now will have - * the effect of taking the interrupt again, in SVC - * mode this time. + * Per ARM DDI 0487G.b section D1.13.4, an ISB (or other + * context synchronization event) is necessary to ensure that + * pending interrupts are taken. */ local_irq_enable(); + isb(); + local_irq_disable(); + + guest_timing_exit_irqoff(); + + local_irq_enable(); - /* - * We do local_irq_enable() before calling guest_exit() so - * that if a timer interrupt hits while running the guest we - * account that tick as being spent in the guest. We enable - * preemption after calling guest_exit() so that if we get - * preempted we make sure ticks after that is not counted as - * guest time. - */ - guest_exit(); trace_kvm_exit(ret, kvm_vcpu_trap_get_class(vcpu), *vcpu_pc(vcpu)); /* Exit types that need handling before we can be preempted */ -- 2.34.1