Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp1070915pxv; Fri, 16 Jul 2021 00:33:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwB2/IkoKkGbtNFleUI9kVaRWGT/KP7S7lGj+CBwqJ98JXhJkzmNbzTFgA6/40oUYAYd2qc X-Received: by 2002:a50:9503:: with SMTP id u3mr7601162eda.135.1626420837964; Fri, 16 Jul 2021 00:33:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626420837; cv=none; d=google.com; s=arc-20160816; b=VerUB5NIYkSpOLsKobPcnZrT3hspIon0ABo4U5A8qlNENGY2PW4iiB4zVhqXnmD6H5 di67eXcW4zqarUXYAC1GTt7OY03A/i+fP36uFHC50NLvTzJPwKDI0T817UvMW62znz2f DdeYJK1IiQvoYf3w8BI6M4np/9MKJJwAPYa9tHBs/sAMYN/YF7EBljzBrvw/3spNvMHr ALc+zj+qbqh0oBl+ZDOjkaFEDQ7KXb54+IeFS+qqPkVQ8igzZ/+QSquFKOvKGq9bmjZE 8fsRS4+xtmby1B5tBQMkC3rCpjxHs2jQmC8TDs6+usBLWIPkczP5ZPEYSLeSV9JuhmA4 qedg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=ibwhoL1eSkERw80Wa+H3P1m75bC+Y/fdfK3KDFajLS8=; b=AD81NY08ju1HtkIEFJl+yWI7DRm9BgJY9uGd3s+RU1+aicMr+MUnqMQ8FSYK7GIpEx DBhwQD0ysY/0RrAtGZljj0jDtV3Lfelxn6SqrZE3nZTuWGY+O4jF1/QJogeJ3FlLzs4P JVCJpdIlYxR0NUyzC67hvaqmtJ+NXnggIzfexLosXyDYmupg1fqLxgRhggh0aomV10UO fGmKIdZs1rtU35xubUZb7Yb5CHLjVnbRJMM4lzAfm5zgbthzGagdyn7MnCRsC+Ck5qh0 EnPaqWEBG++xhWgp7fYZqTYJdqmBYvDPqfo2KhdOMK3hNXUo4JeIZISdbg/azWYFDzRH C9uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yandex.ru header.s=mail header.b="c2Xm/eKF"; 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=yandex.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l20si10473925edt.377.2021.07.16.00.33.34; Fri, 16 Jul 2021 00:33:57 -0700 (PDT) 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=@yandex.ru header.s=mail header.b="c2Xm/eKF"; 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=yandex.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235691AbhGPHfU (ORCPT + 99 others); Fri, 16 Jul 2021 03:35:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235208AbhGPHfT (ORCPT ); Fri, 16 Jul 2021 03:35:19 -0400 X-Greylist: delayed 317 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Fri, 16 Jul 2021 00:32:24 PDT Received: from forward106o.mail.yandex.net (forward106o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::609]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D106EC06175F; Fri, 16 Jul 2021 00:32:24 -0700 (PDT) Received: from iva5-76c5c16f2a53.qloud-c.yandex.net (iva5-76c5c16f2a53.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:7bae:0:640:76c5:c16f]) by forward106o.mail.yandex.net (Yandex) with ESMTP id 454C65062347; Fri, 16 Jul 2021 10:27:05 +0300 (MSK) Received: from iva1-bc1861525829.qloud-c.yandex.net (iva1-bc1861525829.qloud-c.yandex.net [2a02:6b8:c0c:a0e:0:640:bc18:6152]) by iva5-76c5c16f2a53.qloud-c.yandex.net (mxback/Yandex) with ESMTP id YjDptLVuBB-R5H0RC3R; Fri, 16 Jul 2021 10:27:05 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1626420425; bh=ibwhoL1eSkERw80Wa+H3P1m75bC+Y/fdfK3KDFajLS8=; h=In-Reply-To:Message-ID:From:Date:References:To:Subject:Cc; b=c2Xm/eKFF5UgHEnny3tmw7nHfTULIfIVJijV7uecarWPoay+qBsL+ACX65M9lQ613 49RHsyzBPNT0PeRuhAFO0MVzOXY3NYTz+gOMln7au4Z6oxPBZiQt8Lb7hFAHJCZoJe /2GqSvy51AIrTghdTe4ADpAYYlc37WBF/Qmrzoa8= Authentication-Results: iva5-76c5c16f2a53.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by iva1-bc1861525829.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id peBL5hNod9-R42qL6US; Fri, 16 Jul 2021 10:27:04 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: [PATCH] KVM: x86: accept userspace interrupt only if no event is injected To: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: stable@vger.kernel.org References: <20210714213846.854837-1-pbonzini@redhat.com> From: stsp Message-ID: <6f2305c0-77a8-42af-f5e9-2664119b6b2e@yandex.ru> Date: Fri, 16 Jul 2021 10:27:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210714213846.854837-1-pbonzini@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 15.07.2021 00:38, Paolo Bonzini пишет: > Once an exception has been injected, any side effects related to > the exception (such as setting CR2 or DR6) have been taked "taken"? Probably a typo. > place. > Therefore, once KVM sets the VM-entry interruption information > field or the AMD EVENTINJ field, the next VM-entry must deliver that > exception. > > Pending interrupts are processed after injected exceptions, so > in theory it would not be a problem to use KVM_INTERRUPT when > an injected exception is present. However, DOSBox dosemu2 to be precise. > is using > run->ready_for_interrupt_injection to detect interrupt windows > and then using KVM_SET_SREGS/KVM_SET_REGS to inject the > interrupt manually. For this to work, the interrupt window > must be delayed after the completion of the previous event > injection. > > Cc: stable@vger.kernel.org > Reported-by: Stas Sergeev > Tested-by: Stas Sergeev > Fixes: 71cc849b7093 ("KVM: x86: Fix split-irqchip vs interrupt injection window request") > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/x86.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index fe3aaf195292..7fbab29b3569 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -4342,6 +4342,9 @@ static int kvm_vcpu_ioctl_set_lapic(struct kvm_vcpu *vcpu, > > static int kvm_cpu_accept_dm_intr(struct kvm_vcpu *vcpu) > { > + if (kvm_event_needs_reinjection(vcpu)) > + return false; > + kvm_event_needs_reinjection() seems to miss exception.pending check. Don't we need it too? Also perhaps a comment would be good to have to avoid it from disappearing again, as obviously kvm devs tend to overlook the possibility of injecting interrupts by hands.