From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793829135; b=E1ThzLG1j+0crjaNEE70XuaUAgqmfi4ipXDX3v0Lp7mwUadIaQUjAe0LjHze1tnJa4/+ e8wqhCF44iTqAhKhZmINMODVt+xrLc092m2mRgL8NdsT/OSrTqnRJQE6EUJWytkZTl1px eqJWT8t5NnTQJgUoKdUgOtOSTWW8GBj1ARB766lmmE/tyQEAD2Va4VbZ9uVzLPH2/5uRJ GY89QjwGPMREH0Yw6GNShbW1T2ccGYwsaD11Fnt/IJGn3Fcj2847oM9zfcgJ8tyWEV8um xHm5HE0tOc3V1p5skBZjH1Wtqt9xEYEwanFFjxriFS3XK1yrc1EA6XDn6ch15Rc3+3A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793829135; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=h9MOzbYV501l0AXjMg0rtlP+gMvOICzw3dVEuLEJJbc=; b=rvoxjyjQkMYPAN9K+EjYjJ/Iv8s7rYdtbrUZrrIYdXM1alydMbizkojoGDsm27ZMZ3ke xOmQdF3g09B2q4SlC2qy7kRxNCkKcrswNUnb90qYCXQozjsDNBF1mEAiHvwQ6VdaJZ2vm DUcvfPxHsMf8wZkdKNI/GawDR5+gP2Qd3iW7p+aiGcfYGkiNDIhzNgKXWyPlk1hRKIC2r MPSBEqmk0RDdoq1ouvL+LYm2MCczZCzeQ/3jZ3om2rKNUeWkiNXeqSBgocSvUL5DV+XxI f9/Y1VyNjsNXFb9ITglbKmlrR2CI61Ywo8jHIvjdXtA+9/4wCR78abAT6ujH6M33+UQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=lHNu6opy; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93BA36084190; Wed, 4 Nov 2026 21:52:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=lHNu6opy Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30FF21F000C1; Wed, 4 Nov 2026 21:52:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793829135; bh=h9MOzbYV501l0AXjMg0rtlP+gMvOICzw3dVEuLEJJbc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=lHNu6opygGsRsCrwg6pq50iI7WS2X+wwho2Ff8CS63pn4EzeVvZhrdHqFStkHxS0k EhSg+9UGrjlR8/nUJBBHn9GDfE+CG+cbU4R8oHfBP2d909jtYmmuCnKDeIU7T6Ti7I 7DJ81hxPaKctzZ4KGsGXeMXpPMlq8RscI8dSKgkM= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Sean Christopherson Subject: [PATCH 7.3 468/547] KVM: x86: Preserve DR6.BLD (Bus Lock Detect) when delivering #DB payload Date: Wed, 4 Nov 2026 16:10:52 -0500 Message-ID: <20261104211051.655657713@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261104211038.406938024@linuxfoundation.org> References: <20261104211038.406938024@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sean Christopherson commit 719a1d58bf43edd03b271df90b67c58c1e9a7da4 upstream. Preserve Bus Lock Detect if it isn't present in the payload. Unlike RTM, which is explicitly modified on every #DB, DR6.BLD is modified if and only if the #DB is due to a (coincident) Bus Lock Detect. Per Intel's SDM: Other debug exceptions do not modify this bit. And AMD's APM All other #DB exceptions leave DR6[BLD] unmodified, Restore the explicit RTM handling that was clobbered by commit 9a3ecd5e2aa1 ("KVM: X86: Rename DR6_INIT to DR6_ACTIVE_LOW"), as the semantics of any given bit are feature specific, i.e. are obviously not consistent for active-high versus active-low. In other words, while the bug was technically introduced when support for Bus Lock Detect was added, it's really that attempt to genericize handling of active-low bits that set KVM up to fail. Fixes: e8ea85fb280e ("KVM: X86: Add support for the emulation of DR6_BUS_LOCK bit") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930193634.3415089-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman --- arch/x86/kvm/x86.c | 52 ++++++++++++++++++++++++++++++---------------------- 1 file changed, 30 insertions(+), 22 deletions(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -399,30 +399,37 @@ void kvm_deliver_exception_payload(struc switch (ex->vector) { case DB_VECTOR: /* - * "Certain debug exceptions may clear bit 0-3. The - * remaining contents of the DR6 register are never - * cleared by the processor". - */ - vcpu->arch.dr6 &= ~DR_TRAP_BITS; - /* - * In order to reflect the #DB exception payload in guest - * dr6, three components need to be considered: active low - * bit, FIXED_1 bits and active high bits (e.g. DR6_BD, - * DR6_BS and DR6_BT) - * DR6_ACTIVE_LOW contains the FIXED_1 and active low bits. - * In the target guest dr6: - * FIXED_1 bits should always be set. - * Active low bits should be cleared if 1-setting in payload. - * Active high bits should be set if 1-setting in payload. + * DR6 is a mess. Reserved/unused bits are fixed-to-1, and so + * to maintain backwards compatibility with existing software, + * features that use previously-reserved bits have active-low + * semantics, i.e. clear the bit when the feature is present in + * the payload. + * + * Further complicating matters, some DR6 bits are preserved by + * hardware, while others are explicitly modified on every #DB. + * The trap bits are always set based on the payload, as is the + * RTM flag (but it's active low). All other bits are modified + * if and only if a relevant debug exception occurs, e.g. BD, + * BS, and BT are never cleared by hardware, and BLD is never + * set by hardware (when supported, excepting RESET). * - * Note, the payload is compatible with the pending debug - * exceptions/exit qualification under VMX, that active_low bits - * are active high in payload. - * So they need to be flipped for DR6. + * Lastly, the payload does NOT have active-low semantics, e.g. + * so that it's compatible VMX's pending debug exceptions and + * qualification fields, and to avoid bleeding the DR6 madness + * into other KVM code. + * + * To compute DR6: + * + * 1. "Reset" the bits that are modified on all #DBs + * 2. Clear active-low bits that are present in the payload. + * 3. Set active-high bits that are present in the payload. + * 4. Clear fixed-0 bits. + * 5. Set fixed-1 bits. */ - vcpu->arch.dr6 |= DR6_ACTIVE_LOW; - vcpu->arch.dr6 |= ex->payload; - vcpu->arch.dr6 ^= ex->payload & DR6_ACTIVE_LOW; + vcpu->arch.dr6 &= ~DR_TRAP_BITS; + vcpu->arch.dr6 |= DR6_RTM; + vcpu->arch.dr6 &= ~(ex->payload & DR6_ACTIVE_LOW); + vcpu->arch.dr6 |= (ex->payload & ~DR6_ACTIVE_LOW); /* * The #DB payload is defined as compatible with the 'pending @@ -431,6 +438,7 @@ void kvm_deliver_exception_payload(struc * breakpoint), it is reserved and must be zero in DR6. */ vcpu->arch.dr6 &= ~BIT(12); + vcpu->arch.dr6 |= DR6_FIXED_1; break; case PF_VECTOR: vcpu->arch.cr2 = ex->payload;