Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp13381pxb; Thu, 20 Jan 2022 08:10:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJw+12Vh4d6KhBkmwE2drqZYGN516T41u9hyYWJ6MNro2TNhUNNGUowEcFbzYBc1qzh7orFt X-Received: by 2002:a63:6e49:: with SMTP id j70mr32152267pgc.182.1642695015470; Thu, 20 Jan 2022 08:10:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642695015; cv=none; d=google.com; s=arc-20160816; b=INFrz2bn5zSHG8AwHEGE1DdhcHXSEv/WB4hvzDhqOkvNhptADg7bYbejAkyZd9uMfc krdcUyXRMWa05z6O3Qhe00/2L+OyZh1JD4yTApWWX7sSr2Xw2XWuoI6RxGkVyZmfJ9r9 GPjPVTbugoy6NTBXXwqHKIhJh44Cbj0XVu3cmOivSnLIp+78jvw1utNnndZV0V7gDFwi olJVAmQ8pk1LQEU3fe1RcETKRvUK3+X60tWhA51QmNJjNBvcRHqtCMWDz8r9w8NgaXXg gH7al0nPhoSk3SPwXPkYyxKW2VPj9lwiepGMgCM9FxTNr06GOm6ZVw/IW3Q88mYRd5ur pl9g== 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=w8qpEO6I4/xUVzafHGs8HaHpGnCcdfq5t00KZO6/gDw=; b=FpQTW+IwnmqUwJLLqLo6t+GV2W3Kn5RMwHvFdoe4G16JHi/VktMFBRjv/dFfAB1Y+d HYKdgkA+qkt0OEs4qfb5QJMd8Vu8koJIMcf2u1zOWBZo/KjSsyPtJkl/mEl8d3dCvtB8 TrIGOcfPclfb3XfI0rbGeY0Drxf2bfyrC6Gi7UhISJenn2kWy75xJR6bhOhdIiC4QiMA VbuZzVs2n6+FYTwuYLu3yMrlygtwElhhpB5Qvo7az2N4xL3JjCU9dISzaidXrADX2KnK XOglzZRmrAiRDfo358t7LQOV3uZcr5MQfLPWcEgG3+99uwJMfErPhG7hO58HxQxbeZU5 XuLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=nPiGQAGy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m11si3305287pls.431.2022.01.20.08.09.59; Thu, 20 Jan 2022 08:10:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=nPiGQAGy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346644AbiARQKd (ORCPT + 99 others); Tue, 18 Jan 2022 11:10:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243318AbiARQJV (ORCPT ); Tue, 18 Jan 2022 11:09:21 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9997BC06173F; Tue, 18 Jan 2022 08:09:20 -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 sin.source.kernel.org (Postfix) with ESMTPS id EB2E4CE1A3E; Tue, 18 Jan 2022 16:09:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF611C00446; Tue, 18 Jan 2022 16:09:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1642522157; bh=WHbb0OXW8TtFj+QNFHxl7WaQnbFj5FU03ZDyBJMfPKI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nPiGQAGydvKJ8VQGn0x5SZO9WA4vHMB9qBaCpCXjS+V0b0w1xzo8Xus39Fpko0g+f iGtWZAVkoQh5bZTQ7UapOlK/uN/11PoJi8fcNAQvoeu3lFs5iAUniTf7Fih8w6RqME ngHivy4KvW/5kUaAA/sB73ee+ZJmQdGfkjtIDdWI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Hildenbrand , Eric Farman , Christian Borntraeger Subject: [PATCH 5.15 10/28] KVM: s390: Clarify SIGP orders versus STOP/RESTART Date: Tue, 18 Jan 2022 17:05:56 +0100 Message-Id: <20220118160452.224062485@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220118160451.879092022@linuxfoundation.org> References: <20220118160451.879092022@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Farman commit 812de04661c4daa7ac385c0dfd62594540538034 upstream. With KVM_CAP_S390_USER_SIGP, there are only five Signal Processor orders (CONDITIONAL EMERGENCY SIGNAL, EMERGENCY SIGNAL, EXTERNAL CALL, SENSE, and SENSE RUNNING STATUS) which are intended for frequent use and thus are processed in-kernel. The remainder are sent to userspace with the KVM_CAP_S390_USER_SIGP capability. Of those, three orders (RESTART, STOP, and STOP AND STORE STATUS) have the potential to inject work back into the kernel, and thus are asynchronous. Let's look for those pending IRQs when processing one of the in-kernel SIGP orders, and return BUSY (CC2) if one is in process. This is in agreement with the Principles of Operation, which states that only one order can be "active" on a CPU at a time. Cc: stable@vger.kernel.org Suggested-by: David Hildenbrand Signed-off-by: Eric Farman Reviewed-by: Christian Borntraeger Acked-by: David Hildenbrand Link: https://lore.kernel.org/r/20211213210550.856213-2-farman@linux.ibm.com [borntraeger@linux.ibm.com: add stable tag] Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman --- arch/s390/kvm/interrupt.c | 7 +++++++ arch/s390/kvm/kvm-s390.c | 9 +++++++-- arch/s390/kvm/kvm-s390.h | 1 + arch/s390/kvm/sigp.c | 28 ++++++++++++++++++++++++++++ 4 files changed, 43 insertions(+), 2 deletions(-) --- a/arch/s390/kvm/interrupt.c +++ b/arch/s390/kvm/interrupt.c @@ -2115,6 +2115,13 @@ int kvm_s390_is_stop_irq_pending(struct return test_bit(IRQ_PEND_SIGP_STOP, &li->pending_irqs); } +int kvm_s390_is_restart_irq_pending(struct kvm_vcpu *vcpu) +{ + struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int; + + return test_bit(IRQ_PEND_RESTART, &li->pending_irqs); +} + void kvm_s390_clear_stop_irq(struct kvm_vcpu *vcpu) { struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int; --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -4642,10 +4642,15 @@ int kvm_s390_vcpu_stop(struct kvm_vcpu * } } - /* SIGP STOP and SIGP STOP AND STORE STATUS has been fully processed */ + /* + * Set the VCPU to STOPPED and THEN clear the interrupt flag, + * now that the SIGP STOP and SIGP STOP AND STORE STATUS orders + * have been fully processed. This will ensure that the VCPU + * is kept BUSY if another VCPU is inquiring with SIGP SENSE. + */ + kvm_s390_set_cpuflags(vcpu, CPUSTAT_STOPPED); kvm_s390_clear_stop_irq(vcpu); - kvm_s390_set_cpuflags(vcpu, CPUSTAT_STOPPED); __disable_ibs_on_vcpu(vcpu); for (i = 0; i < online_vcpus; i++) { --- a/arch/s390/kvm/kvm-s390.h +++ b/arch/s390/kvm/kvm-s390.h @@ -418,6 +418,7 @@ void kvm_s390_destroy_adapters(struct kv int kvm_s390_ext_call_pending(struct kvm_vcpu *vcpu); extern struct kvm_device_ops kvm_flic_ops; int kvm_s390_is_stop_irq_pending(struct kvm_vcpu *vcpu); +int kvm_s390_is_restart_irq_pending(struct kvm_vcpu *vcpu); void kvm_s390_clear_stop_irq(struct kvm_vcpu *vcpu); int kvm_s390_set_irq_state(struct kvm_vcpu *vcpu, void __user *buf, int len); --- a/arch/s390/kvm/sigp.c +++ b/arch/s390/kvm/sigp.c @@ -288,6 +288,34 @@ static int handle_sigp_dst(struct kvm_vc if (!dst_vcpu) return SIGP_CC_NOT_OPERATIONAL; + /* + * SIGP RESTART, SIGP STOP, and SIGP STOP AND STORE STATUS orders + * are processed asynchronously. Until the affected VCPU finishes + * its work and calls back into KVM to clear the (RESTART or STOP) + * interrupt, we need to return any new non-reset orders "busy". + * + * This is important because a single VCPU could issue: + * 1) SIGP STOP $DESTINATION + * 2) SIGP SENSE $DESTINATION + * + * If the SIGP SENSE would not be rejected as "busy", it could + * return an incorrect answer as to whether the VCPU is STOPPED + * or OPERATING. + */ + if (order_code != SIGP_INITIAL_CPU_RESET && + order_code != SIGP_CPU_RESET) { + /* + * Lockless check. Both SIGP STOP and SIGP (RE)START + * properly synchronize everything while processing + * their orders, while the guest cannot observe a + * difference when issuing other orders from two + * different VCPUs. + */ + if (kvm_s390_is_stop_irq_pending(dst_vcpu) || + kvm_s390_is_restart_irq_pending(dst_vcpu)) + return SIGP_CC_BUSY; + } + switch (order_code) { case SIGP_SENSE: vcpu->stat.instruction_sigp_sense++;