Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Shivansh Dhiman <shivansh.dhiman@amd.com>
To: Sean Christopherson <seanjc@google.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>,
	Shivansh Dhiman <shivansh.dhiman@amd.com>
Subject: Re: [PATCH v4 4/5] KVM: SVM: Turn DEBUGCTL_RESERVED_BITS into a helper
Date: Thu, 1 Oct 2026 03:59:35 +0530	[thread overview]
Message-ID: <20b2ef29-c87d-45f0-9977-5a1d9d5bc69d@amd.com> (raw)
In-Reply-To: <araypKKIb0-Cp_iL@google.com>



On 25-09-26 23:13, Sean Christopherson wrote:
> On Tue, Jul 21, 2026, Shivansh Dhiman wrote:
>> Replace the static DEBUGCTL_RESERVED_BITS macro with a helper,
>> svm_get_debugctl_reserved_bits(), and plumb the vCPU into
>> svm_copy_vmrun_state() so it can be passed to the helper.
>>
>> The vCPU argument is currently unused (marked __maybe_unused).
> 
> There's no need to tag parameters __maybe_unused, AFAIK no compiler ever complains
> about parameters, only local/global variables.

I remember my compiler giving some warning about the unused parameters IIRC.
So, I added it to preserve clean builds between patches. Anyway, I'll check
my build environment once.

>> diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
>> index d52010e4de97..696f1b4b8f8f 100644
>> --- a/arch/x86/kvm/svm/svm.h
>> +++ b/arch/x86/kvm/svm/svm.h
>> @@ -783,7 +783,10 @@ BUILD_SVM_MSR_BITMAP_HELPERS(bool, test, test)
>>  BUILD_SVM_MSR_BITMAP_HELPERS(void, clear, __clear)
>>  BUILD_SVM_MSR_BITMAP_HELPERS(void, set, __set)
>>  
>> -#define DEBUGCTL_RESERVED_BITS (~DEBUGCTLMSR_LBR)
>> +static inline u64 svm_get_debugctl_reserved_bits(struct kvm_vcpu *vcpu __maybe_unused)
> 
> The polarity is cumbersome and annoyingly different than VMX, quite silly since
> most paths care about supported bits, and the resulting code once BLD comes along
> is downright ridiculous.  Invert the polarity so that we end up with
> 
>   static inline u64 svm_get_supported_debugctl(struct kvm_vcpu *vcpu)
>   {
> 	u64 debugctl = DEBUGCTLMSR_LBR;
> 
> 	if (guest_cpu_cap_has(vcpu, X86_FEATURE_BUS_LOCK_DETECT))
> 		debugctl |= DEBUGCTLMSR_BUS_LOCK_DETECT;
> 
> 	return debugctl;
>   }

Checked the VMX side of it, and this looks better. Thanks.

-Shivansh

> 
> 
> instead of:
> 
>   static inline u64 svm_get_debugctl_reserved_bits(struct kvm_vcpu *vcpu)
>   {
>        u64 debugctl = DEBUGCTLMSR_LBR;
> 
>        if (guest_cpu_cap_has(vcpu, X86_FEATURE_BUS_LOCK_DETECT))
>                debugctl |= DEBUGCTLMSR_BUS_LOCK_DETECT;
> 
>        return ~debugctl;
>   }


  reply	other threads:[~2026-09-30 22:29 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
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 [this message]
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=20b2ef29-c87d-45f0-9977-5a1d9d5bc69d@amd.com \
    --to=shivansh.dhiman@amd.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=seanjc@google.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