From: Sean Christopherson <seanjc@google.com>
To: Shivansh Dhiman <shivansh.dhiman@amd.com>
Cc: pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
kvm@vger.kernel.org, x86@kernel.org, yosry@kernel.org,
jmattson@google.com, thomas.lendacky@amd.com,
nikunj.dadhania@amd.com, ravi.bangoria@amd.com,
santosh.shukla@amd.com
Subject: Re: [PATCH v4 3/5] KVM: nSVM: Sanitize nested DR6 using kvm_dr6_fixed()
Date: Fri, 25 Sep 2026 10:39:28 -0700 [thread overview]
Message-ID: <arax0JmdoGYoSpGw@google.com> (raw)
In-Reply-To: <20260721050600.87268-4-shivansh.dhiman@amd.com>
The shortlog is again not precise enough. With this:
KVM: nSVM: Sanitize nested DR6 using kvm_dr6_fixed
the reader doesn't actually know what behavior is being modified. It's also way
too literal; the shortlog+changelog should strive to describe the change in human-
friendly words, e.g. in conversational language, not be a play-by-play of the code
change. And that matters in this case, because the poorly named kvm_dr6_fixed()
makes it even hard to understand what is actually happening.
KVM: nSVM: Don't assume all active-low bits DR6 are fixed-1
On Tue, Jul 21, 2026, Shivansh Dhiman wrote:
> When preparing vmcb02 for nested VMRUN, KVM ORs DR6_ACTIVE_LOW into the
> guest DR6 to force the fixed bits to 1. DR6_ACTIVE_LOW forces bit 11
> (DR6_BUS_LOCK) to 1 unconditionally.
>
> DR6_BUS_LOCK is active-low (the CPU clears it to 0 to report a bus lock), so
> forcing it to 1 unconditionally would prevent an L2 from ever observing a
> bus lock (DR6.BLD == 0) across a nested VMRUN.
>
> Use kvm_dr6_fixed() instead, which forces DR6_RTM and DR6_BUS_LOCK based on
We should kill off DR6_FIXED_1 and rename kvm_dr6_fixed() to kvm_get_dr6_fixed_1()
as prep patches.
As above, the changelog is too much of a play-by-play. The names of the macros
don't matter, and knowing the exact bit position isn't necessary to describe and
understand the change.
When preparing vmcb02 for nested VMRUN, force only the actual fixed-1 bits
instead of setting all active-low bits. The flaw is currently benign, as
the only active-low bits supported by KVM are RTM (Restricted Transactional
Memory) and BLD (Bus Lock Detect), neither of which is currently supported
on SVM, but that's about to change. I.e. this will break upcoming Bus Lock
Detect support as the guest will never see DR6.BLD=0.
> the guest's CPUID. DR6_RTM is a reserved bit on AMD and is thus always set
> to 1. DR6_BUS_LOCK is left writable once the guest supports Bus Lock
> Detect.
next prev parent reply other threads:[~2026-09-25 17:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 5:05 [PATCH v4 0/5] KVM: SVM: Add Bus Lock Detect support and refactor LBRV Shivansh Dhiman
2026-07-21 5:05 ` [PATCH v4 1/5] KVM: SVM: Refactor svm_update_lbrv() Shivansh Dhiman
2026-07-21 6:40 ` Nikunj A. Dadhania
2026-07-21 9:16 ` Shivansh Dhiman
2026-09-25 17:31 ` Sean Christopherson
2026-09-30 22:16 ` Shivansh Dhiman
2026-07-21 5:05 ` [PATCH v4 2/5] KVM: nSVM: Disable LBRV in nested control cache when unsupported Shivansh Dhiman
2026-07-21 5:05 ` [PATCH v4 3/5] KVM: nSVM: Sanitize nested DR6 using kvm_dr6_fixed() Shivansh Dhiman
2026-07-21 5:21 ` sashiko-bot
2026-09-25 17:26 ` Sean Christopherson
2026-09-25 17:39 ` Sean Christopherson [this message]
2026-09-30 22:16 ` Shivansh Dhiman
2026-07-21 5:05 ` [PATCH v4 4/5] KVM: SVM: Turn DEBUGCTL_RESERVED_BITS into a helper Shivansh Dhiman
2026-09-25 17:43 ` Sean Christopherson
2026-09-30 22:29 ` Shivansh Dhiman
2026-07-21 5:06 ` [PATCH v4 5/5] KVM: SVM: Add Bus Lock Detect support Shivansh Dhiman
2026-09-25 17:45 ` [PATCH v4 0/5] KVM: SVM: Add Bus Lock Detect support and refactor LBRV Sean Christopherson
2026-09-25 23:01 ` Sean Christopherson
2026-09-28 18:38 ` Shivansh Dhiman
2026-10-01 20:18 ` Shivansh Dhiman
2026-10-01 23:11 ` Sean Christopherson
2026-09-30 23:05 ` Shivansh Dhiman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arax0JmdoGYoSpGw@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj.dadhania@amd.com \
--cc=pbonzini@redhat.com \
--cc=ravi.bangoria@amd.com \
--cc=santosh.shukla@amd.com \
--cc=shivansh.dhiman@amd.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=yosry@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox