All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Xin Li <xin@zytor.com>
Cc: Sohil Mehta <sohil.mehta@intel.com>,
	linux-kernel@vger.kernel.org,  kvm@vger.kernel.org,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	 dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	 pbonzini@redhat.com, peterz@infradead.org, brgerst@gmail.com,
	 tony.luck@intel.com, fenghuay@nvidia.com
Subject: Re: [PATCH v2 1/2] x86/traps: Initialize DR6 by writing its architectural reset value
Date: Wed, 18 Jun 2025 14:24:07 -0700	[thread overview]
Message-ID: <aFMudwy2uO5V8vM5@google.com> (raw)
In-Reply-To: <25896236-de8d-4bd9-8a27-da407c0e5a38@zytor.com>

On Tue, Jun 17, 2025, Xin Li wrote:
> On 6/17/2025 1:47 PM, Sean Christopherson wrote:
> > On Tue, Jun 17, 2025, Sohil Mehta wrote:
> > Note, DR6_VOLATILE and DR6_FIXED_1 aren't necessarily aligned with the current
> > architectural definitions (I haven't actually checked),
> 
> I'm not sure what do you mean by "architectural definitions" here.

I was trying to say that there may be bits that have been defined in the SDM,
but are not yet makred as "supported" in DR6_VOLATILE, i.e. that are "incorrectly"
marked as DR6_FIXED_1 (in quotes, because from KVM's perspective, the bits *are*
fixed-1, for the guest).
 
> However because zeroing DR6 leads to different DR6 values depending on
> whether the CPU supports BLD:
> 
>   1) On CPUs with BLD support, DR6 becomes 0xFFFF07F0 (bit 11, DR6.BLD,
>      is cleared).
> 
>   2) On CPUs without BLD, DR6 becomes 0xFFFF0FF0.
> 
> DR6_FIXED_1, if it is still defined to include all bits that can't be
> cleared, is a constant value only on a *specific* CPU architecture,
> i.e., it is not a constant value on all CPU implementations.
> 
> 
> > rather they are KVM's
> > view of the world, i.e. what KVM supports from a virtualization perspective.
> 
> So KVM probably should expose the fixed 1s in DR6 to the guest depending on
> which features, such as BLD or RTM, are enabled and visible to the
> guest or not?
> 
> (Sorry I haven't looked into how the macro DR6_FIXED_1 is used in KVM,
> maybe it's already used in such a way)

Yep, that's exactly what KVM does.  DR6_FIXED_1 is the set of bits that KVM
doesn't yet support for *any* guest.  The per-vCPU set of a fixed-1 bits starts
with DR6_FIXED_1, and adds in bits for features that aren't supported/exposed
to the guest. 

static u64 kvm_dr6_fixed(struct kvm_vcpu *vcpu)
{
	u64 fixed = DR6_FIXED_1;

	if (!guest_cpu_cap_has(vcpu, X86_FEATURE_RTM))
		fixed |= DR6_RTM;

	if (!guest_cpu_cap_has(vcpu, X86_FEATURE_BUS_LOCK_DETECT))
		fixed |= DR6_BUS_LOCK;
	return fixed;
}

  reply	other threads:[~2025-06-18 21:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-17  7:32 [PATCH v2 0/2] x86/traps: Fix DR6/DR7 initialization Xin Li (Intel)
2025-06-17  7:32 ` [PATCH v2 1/2] x86/traps: Initialize DR6 by writing its architectural reset value Xin Li (Intel)
2025-06-17  9:03   ` Peter Zijlstra
2025-06-17 22:49     ` Xin Li
2025-06-17 18:23   ` Sohil Mehta
2025-06-17 20:47     ` Sean Christopherson
2025-06-17 23:10       ` Sohil Mehta
2025-06-18  0:42         ` Xin Li
2025-06-17 23:57       ` Xin Li
2025-06-18 21:24         ` Sean Christopherson [this message]
2025-06-18 21:55           ` Xin Li
2025-06-19  5:16       ` Maciej W. Rozycki
2025-06-17  7:32 ` [PATCH v2 2/2] x86/traps: Initialize DR7 " Xin Li (Intel)
2025-06-17 13:35   ` Sean Christopherson
2025-06-17 23:08     ` Xin Li
2025-06-18  0:15       ` Xin Li
2025-06-18  3:34         ` H. Peter Anvin
2025-06-17 23:10   ` Sohil Mehta
2025-06-18  0:44     ` Xin Li
2025-06-17  9:05 ` [PATCH v2 0/2] x86/traps: Fix DR6/DR7 initialization Peter Zijlstra
2025-06-17 17:55 ` Sohil Mehta

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=aFMudwy2uO5V8vM5@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghuay@nvidia.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sohil.mehta@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.