From nobody Tue Apr 7 06:55:05 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C6B52ECAAA1 for ; Tue, 30 Aug 2022 23:18:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232012AbiH3XSQ (ORCPT ); Tue, 30 Aug 2022 19:18:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231349AbiH3XRp (ORCPT ); Tue, 30 Aug 2022 19:17:45 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DCCBA0638 for ; Tue, 30 Aug 2022 16:16:31 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-32a115757b6so191759857b3.13 for ; Tue, 30 Aug 2022 16:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc; bh=UFryeljcs8yQ8P4nGe9cXbKFWzMUyn5inoM+2kTYTzE=; b=EtVUiRa6EYAYdMJY9HfkJeXfOfiZiT4gT4+hiB9cNcvjsBLonDBCQ25vkcPRblbiw3 blpZpdKD90K9BUSKxGL4lNYR9+Ds0LZa/DbOby02tQoFffneL8QzRZZkQHEro02d9s0b oZ+n6ytcHPci31xeQg4NEs8/i2imOB7ud9FFZB3WcAh0i57fTxgiV+Oi767cVJG0BktE pPCHhg1FPtYixEgnG2dKEMHTAKDR3QgGCWQF24sEl8dttoG4dtBqdMzf/fE0yXLK7f/K TrOTKGQS9RL1g4nBLPkKH99liVpygVyE+ARO6U1xWmQoU4CfTQTz/gOzgrAo+XXUDlM1 lqSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc; bh=UFryeljcs8yQ8P4nGe9cXbKFWzMUyn5inoM+2kTYTzE=; b=hbRW/AX0O79vYIfjweHIIEp09xS9vOuwrtBgla2DtQ1rfB+2bTcrJFK5NbX+LE8DpT JMb2B/N+rhAj8HBIDSfm6LdhXpBfZ2Sv6F29JsKoLeDAvNeqLyrbuw8CDthtNOFrI0AS ntiiDdux7zuyHqfTAq9JIKqYge3v/NX14zp13tJPEtKBGfhwdG5dVn/bwRVac790stAR uHNGazSxSDhRW6fVArPdCk7/cc+l8F9UoXGfnFIx6mA5BY7tGAT7V3Kq9ioQ8C+3ryTq lE/bfK/Bshk0fhe9/RqU5k8JhysK4g6CXSbu0W1V8uPdrY2osPhtEHY3gBR/q3OiIT5g FxaQ== X-Gm-Message-State: ACgBeo26vNdTew5N3+Gm/58pqTDwjgGT88MTsAqN5ppdXU803Wvn1xw9 2pdHCzrsyOvBy9wAltaQDvDFtUG2Xxo= X-Google-Smtp-Source: AA6agR7uWZY2ecbTO1BssBcoMyC7CW18mv5KMlHRCii6+M29k+np2dM/cluhSbv8k7TUgk+wPkXCIQY7gCk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:add1:0:b0:691:3523:13c8 with SMTP id d17-20020a25add1000000b00691352313c8mr14033133ybe.52.1661901390052; Tue, 30 Aug 2022 16:16:30 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 30 Aug 2022 23:15:55 +0000 In-Reply-To: <20220830231614.3580124-1-seanjc@google.com> Mime-Version: 1.0 References: <20220830231614.3580124-1-seanjc@google.com> X-Mailer: git-send-email 2.37.2.672.g94769d06f0-goog Message-ID: <20220830231614.3580124-9-seanjc@google.com> Subject: [PATCH v5 08/27] KVM: x86: Treat #DBs from the emulator as fault-like (code and DR7.GD=1) From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jim Mattson , Maxim Levitsky , Oliver Upton , Peter Shier Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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=3D1 on the stack, keep the current behavior of not setting RF=3D1 for #DBs. Intel and AMD explicitly state RF isn't set on code #DBs, so exempting by failing the "=3D=3D 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=3D1, 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 --- arch/x86/kvm/x86.c | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 013580c355d7..39d3eadc43a2 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -533,6 +533,7 @@ static int exception_class(int vector) #define EXCPT_TRAP 1 #define EXCPT_ABORT 2 #define EXCPT_INTERRUPT 3 +#define EXCPT_DB 4 =20 static int exception_type(int vector) { @@ -543,8 +544,14 @@ static int exception_type(int vector) =20 mask =3D 1 << vector; =20 - /* #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; =20 if (mask & ((1 << DF_VECTOR) | (1 << MC_VECTOR))) @@ -8832,6 +8839,12 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, g= pa_t cr2_or_gpa, unsigned long rflags =3D static_call(kvm_x86_get_rflags)(vcpu); toggle_interruptibility(vcpu, ctxt->interruptibility); vcpu->arch.emulate_regs_need_sync_to_vcpu =3D 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) =3D=3D EXCPT_TRAP) { kvm_pmu_trigger_event(vcpu, PERF_COUNT_HW_INSTRUCTIONS); @@ -9755,6 +9768,16 @@ static int inject_pending_event(struct kvm_vcpu *vcp= u, bool *req_immediate_exit) =20 /* try to inject new event if pending */ if (vcpu->arch.exception.pending) { + /* + * Fault-class exceptions, except #DBs, set RF=3D1 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=3D0). + * + * 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) =3D=3D EXCPT_FAULT) __kvm_set_rflags(vcpu, kvm_get_rflags(vcpu) | X86_EFLAGS_RF); --=20 2.37.2.672.g94769d06f0-goog