Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3820768imw; Mon, 11 Jul 2022 17:02:40 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uXwgwH/JvV4ixXpLJUc0ZLwfPuze9jgCo3aKoq2Ruw3xOVJ1+fjjvnBxEFUhHWbqSLjReH X-Received: by 2002:a17:902:8491:b0:16b:9c47:b4c6 with SMTP id c17-20020a170902849100b0016b9c47b4c6mr21447926plo.42.1657584160029; Mon, 11 Jul 2022 17:02:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657584160; cv=none; d=google.com; s=arc-20160816; b=BEVFrYosXBLyog2TWDOiqsNjy7E+P6qNyNqgzn3ANkXOFJAkDVOZp4QXcQwxDqkNmo Ma5Dy/l4ilRocxOBPJi7aGfQpiKInxbAxO35s/lxWNzj/Bly8WKVGRWYPtoSmyVOhma0 yRaGrgQmaHtu6yin1kSZHx7cAFLSIP+Q6mYBijIvdDZAO1MUD6n2xZjKROe3RXg2lIKc Oib9dRiN0Y3a3UpGUMQfU081OxNHziQ2w92vAsKn8ZspUBRQaWZNMpzli0xkp+DygtBz AVFlaVZ1PGhCDa3gFiGfi1167cb8iRzu7wwdFDnZzhQ8VLi9InGxqw8Ob0DYAmgZLv/7 QbGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:references:mime-version :message-id:in-reply-to:date:reply-to:dkim-signature; bh=l1YVI1jymWKPwtQYaErfNq6OCrckplvwfXfah/8A/rc=; b=DGEel6saWf9K3BexaRZOYZPCdmZ9G0pOXJPYyx4lVcAHk6PziwXwWlsLHbyowNoRvk T1SXAM09CZoa0hqQkDn1n3UTuozdVgINm73RoG2CjG8bRLmSIoOHqA8GpnzmGyHdHGhQ Ta9/wDPQCoKUjSRxidFqhmEQDuO8e1uEK5KUG7qIf+0EwOAVtfs0lQsqW01Z9KWPmP/C A7D4vKYeUhW5B9qLtAdHthecoN5YmOlAZoPYHwZKzagYBkw9YQnMQJT0Fnc1jXA8td7v h7nuyV6W4TnhJwxj/QwiTLiefS5GM7GKqnFyL0dD5dxcLCHneZMATLQP8LVTmYX6sbtw 6a7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=SVmaSc+l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f15-20020a63754f000000b0040d28f1a110si13578059pgn.490.2022.07.11.17.02.28; Mon, 11 Jul 2022 17:02:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=SVmaSc+l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231392AbiGKX20 (ORCPT + 99 others); Mon, 11 Jul 2022 19:28:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231608AbiGKX2Y (ORCPT ); Mon, 11 Jul 2022 19:28:24 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 662C78AB1F for ; Mon, 11 Jul 2022 16:28:16 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id c18-20020a170903235200b0016c37f6d48cso4016487plh.19 for ; Mon, 11 Jul 2022 16:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=l1YVI1jymWKPwtQYaErfNq6OCrckplvwfXfah/8A/rc=; b=SVmaSc+lEZoy1vyMnxQkmZX7Wb3FG6N+CBqp55C3XwrUZ33I51/VK8pLmMruirVuhl z+Mxx1RY+uXt8Nj17/lLRC/NMw6LZlLUmrjDVupkRHj52stwdyergUPLjOnoeiM1Bhw1 JyUdkak654zIqYhT1QsApidufgOzzlNHcW9pGtbuQKv6mU5pWGmx+dFYm19CXpOpZt9B wLFC4Ykc9rohW/Q4YHFEpyMN/CencJi4JOKSdSQkLa5C688mjx8lTKrwZSTGM3FSgAl6 1+Ppb7K6Dx4e2fPDH3isw/w9weHrROniS6nUzTv8XOEPRLqIXEZf7ES5nhlyAeckGmES BMZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=l1YVI1jymWKPwtQYaErfNq6OCrckplvwfXfah/8A/rc=; b=UBlMu8kNHx+Px4VqDdWdY/+IZIFdSxRqh1S4HlEWTK4zZF7227Wp8p9NPbP5DMNIHF 92GOsLPp4zz5m9PywosczkF0YyzsCahhrncwLHVxjVHOeKRTzmO0qn5SxAeOExVuqQf1 AHsULWU707NJ9T35ZzVX53TomdxIuhIGdxloBFm7HosSYhCJZEzncdZG9//Jp9HaTZOA +8iJY6BpV13gRM+LuREhVc4wVg15KOOg/6SC9CF9V6pwcHD402LftC2RNZevqxMpe7OK Ztlb85cAKWidWtr91X+LaLi6gxZAkqAZuUGPKuUX+RJ5X191HhLIP+lOjtpUCcd9SAIc sfuw== X-Gm-Message-State: AJIora+EcXn6okF5rKCay4pN9+z0QgHCLTDc/hI/eA1QvanbcfBHaU/r MEmrAhWLhnsxfOIdod/8h6f+eieBYvw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:474c:b0:1ec:f898:d85b with SMTP id y12-20020a17090a474c00b001ecf898d85bmr895865pjg.11.1657582095847; Mon, 11 Jul 2022 16:28:15 -0700 (PDT) Reply-To: Sean Christopherson Date: Mon, 11 Jul 2022 23:27:50 +0000 In-Reply-To: <20220711232750.1092012-1-seanjc@google.com> Message-Id: <20220711232750.1092012-4-seanjc@google.com> Mime-Version: 1.0 References: <20220711232750.1092012-1-seanjc@google.com> X-Mailer: git-send-email 2.37.0.144.g8ac04bfd2-goog Subject: [PATCH 3/3] KVM: x86: WARN only once if KVM leaves a dangling userspace I/O request From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+760a73552f47a8cd0fd9@syzkaller.appspotmail.com, Tetsuo Handa , Hou Wenlong Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham 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 Change a WARN_ON() to separate WARN_ON_ONCE() if KVM has an outstanding PIO or MMIO request without an associated callback, i.e. if KVM queued a userspace I/O exit but didn't actually exit to userspace before moving on to something else. Warning on every KVM_RUN risks spamming the kernel if KVM gets into a bad state. Opportunistically split the WARNs so that it's easier to triage failures when a WARN fires. Deliberately do not use KVM_BUG_ON(), i.e. don't kill the VM. While the WARN is all but guaranteed to fire if and only if there's a KVM bug, a dangling I/O request does not present a danger to KVM (that flag is truly truly consumed only in a single emulator path), and any such bug is unlikely to be fatal to the VM (KVM essentially failed to do something it shouldn't have tried to do in the first place). In other words, note the bug, but let the VM keep running. Signed-off-by: Sean Christopherson --- arch/x86/kvm/x86.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 567d13405445..50dc55996416 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10847,8 +10847,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) r = cui(vcpu); if (r <= 0) goto out; - } else - WARN_ON(vcpu->arch.pio.count || vcpu->mmio_needed); + } else { + WARN_ON_ONCE(vcpu->arch.pio.count); + WARN_ON_ONCE(vcpu->mmio_needed); + } if (kvm_run->immediate_exit) { r = -EINTR; -- 2.37.0.144.g8ac04bfd2-goog