From patchwork Wed Oct 19 08:24:24 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 5347 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp295981wrs; Wed, 19 Oct 2022 05:26:41 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6QubRwboaof28G7TevxLJEEYzH/dW0q6g333D6U4vg6jhCTsIPm9yfHif0JV2xjsTGYplU X-Received: by 2002:a05:6402:501b:b0:459:df91:983 with SMTP id p27-20020a056402501b00b00459df910983mr6946653eda.85.1666182401775; Wed, 19 Oct 2022 05:26:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666182401; cv=none; d=google.com; s=arc-20160816; b=XPevMbmkmhxo4KZD9AAhw+B8nWgckDWdH88itQDPYvrueGBod1aFlJcqDBfxD9uBoq b64Xc5wsEaXtZ4LmbVdnfveh2YJ3TlwSBoX0oYjuCpADEEnEeClKF9ShzaBEu2QPsyIr uT0u2Djrb1Xw4lKt5RaqYtMmcndLDjBbS36g4TtITzDs/Rqb6gHySur3oPE79NOL4JW3 bbSqo+hf9M0RLYNButZePijwOdFFTUr2cgkM1P7zrWAQfqRkRSl2T1bWA7eiiDNyM3Ne venZLNRh6uhJEAKvfuQl0h6qiXc/R5DLpXI9hkVQS1OuOw92AE/yzEYNweChCUuXO3xY 5CBQ== 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=TTQLYrSg6+2/setW+s1hOuUiQJ1HN5fg/PvIZh8vLO8=; b=kpJj7fB0rx7d0YLvxHZugbYNZtTm0HiSSB+r2AhFglq/UnOyhZH8TV2Nfj+LyYj5VR g3siNp3AMf74iO0tC/1WdtVQc0JZVxfWY5o0rOe+ciohVNFFGEvBh9WR/dVbcnqVTSdr EHBnp7LAz9SgLBmD7uOibvhOw+A3GjRZmQbMS+Z3IMDlJ1jIRsJ3XPys3hlFhCy/ZK9E syetNV7Pu29WUN7EzZfQZK+bPVuZ6U/Zf0+r8GuE8xm2VBRd/o2Yh7M01cT+eJsvfU2R yYkQySx0w3p7gkmF+nboL/rxEVtmToy65jXcpz58DyDxBl1rTVhRd2Dp6fwuCeU23+CM uA2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ZrIltA5g; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ht17-20020a170907609100b00782f3e3bb71si14832899ejc.912.2022.10.19.05.26.07; Wed, 19 Oct 2022 05:26:41 -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=@linuxfoundation.org header.s=korg header.b=ZrIltA5g; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232873AbiJSMQe (ORCPT + 99 others); Wed, 19 Oct 2022 08:16:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229463AbiJSMQB (ORCPT ); Wed, 19 Oct 2022 08:16:01 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9965620982; Wed, 19 Oct 2022 04:52:14 -0700 (PDT) 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 89DDEB82313; Wed, 19 Oct 2022 08:45:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5E90C4314F; Wed, 19 Oct 2022 08:45:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666169157; bh=b5rhGy6HGSiQ2e/PIO9XZf9ax5EpqjitVWvYpPFEra4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZrIltA5guccu0hHy2yx/1x6Fh7tEpnqh3KAOMFQlxc82aEXrNYTqXLk0hs34RWgEH W3EOWq32oaWzLfgFDDhr9Q271/CLJ9gPPJKbknsPuXOs1DwvXy+c0Gdf55IL67R1jP RvrS8QGXcPAUxyhsrQ/XYO4smLwj/kV3ZcAMH/jI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sean Christopherson , Maxim Levitsky , Paolo Bonzini Subject: [PATCH 6.0 177/862] KVM: x86: Treat #DBs from the emulator as fault-like (code and DR7.GD=1) Date: Wed, 19 Oct 2022 10:24:24 +0200 Message-Id: <20221019083257.781526962@linuxfoundation.org> X-Mailer: git-send-email 2.38.0 In-Reply-To: <20221019083249.951566199@linuxfoundation.org> References: <20221019083249.951566199@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747118878261936329?= X-GMAIL-MSGID: =?utf-8?q?1747118878261936329?= From: Sean Christopherson commit 5623f751bd9c438ed12840e086f33c4646440d19 upstream. Add a dedicated "exception type" for #DBs, as #DBs can be fault-like or trap-like depending the sub-type of #DB, and effectively defer the decision of what to do with the #DB to the caller. For the emulator's two calls to exception_type(), treat the #DB as fault-like, as the emulator handles only code breakpoint and general detect #DBs, both of which are fault-like. For event injection, which uses exception_type() to determine whether to set EFLAGS.RF=1 on the stack, keep the current behavior of not setting RF=1 for #DBs. Intel and AMD explicitly state RF isn't set on code #DBs, so exempting by failing the "== EXCPT_FAULT" check is correct. The only other fault-like #DB is General Detect, and despite Intel and AMD both strongly implying (through omission) that General Detect #DBs should set RF=1, hardware (multiple generations of both Intel and AMD), in fact does not. Through insider knowledge, extreme foresight, sheer dumb luck, or some combination thereof, KVM correctly handled RF for General Detect #DBs. Fixes: 38827dbd3fb8 ("KVM: x86: Do not update EFLAGS on faulting emulation") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky Link: https://lore.kernel.org/r/20220830231614.3580124-9-seanjc@google.com Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman --- arch/x86/kvm/x86.c | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -528,6 +528,7 @@ static int exception_class(int vector) #define EXCPT_TRAP 1 #define EXCPT_ABORT 2 #define EXCPT_INTERRUPT 3 +#define EXCPT_DB 4 static int exception_type(int vector) { @@ -538,8 +539,14 @@ static int exception_type(int vector) mask = 1 << vector; - /* #DB is trap, as instruction watchpoints are handled elsewhere */ - if (mask & ((1 << DB_VECTOR) | (1 << BP_VECTOR) | (1 << OF_VECTOR))) + /* + * #DBs can be trap-like or fault-like, the caller must check other CPU + * state, e.g. DR6, to determine whether a #DB is a trap or fault. + */ + if (mask & (1 << DB_VECTOR)) + return EXCPT_DB; + + if (mask & ((1 << BP_VECTOR) | (1 << OF_VECTOR))) return EXCPT_TRAP; if (mask & ((1 << DF_VECTOR) | (1 << MC_VECTOR))) @@ -8801,6 +8808,12 @@ writeback: unsigned long rflags = static_call(kvm_x86_get_rflags)(vcpu); toggle_interruptibility(vcpu, ctxt->interruptibility); vcpu->arch.emulate_regs_need_sync_to_vcpu = false; + + /* + * Note, EXCPT_DB is assumed to be fault-like as the emulator + * only supports code breakpoints and general detect #DB, both + * of which are fault-like. + */ if (!ctxt->have_exception || exception_type(ctxt->exception.vector) == EXCPT_TRAP) { kvm_pmu_trigger_event(vcpu, PERF_COUNT_HW_INSTRUCTIONS); @@ -9724,6 +9737,16 @@ static int inject_pending_event(struct k /* try to inject new event if pending */ if (vcpu->arch.exception.pending) { + /* + * Fault-class exceptions, except #DBs, set RF=1 in the RFLAGS + * value pushed on the stack. Trap-like exception and all #DBs + * leave RF as-is (KVM follows Intel's behavior in this regard; + * AMD states that code breakpoint #DBs excplitly clear RF=0). + * + * Note, most versions of Intel's SDM and AMD's APM incorrectly + * describe the behavior of General Detect #DBs, which are + * fault-like. They do _not_ set RF, a la code breakpoints. + */ if (exception_type(vcpu->arch.exception.nr) == EXCPT_FAULT) __kvm_set_rflags(vcpu, kvm_get_rflags(vcpu) | X86_EFLAGS_RF);