From: Manali Shukla <manali.shukla@amd.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
pbonzini@redhat.com, shuah@kernel.org, nikunj@amd.com,
thomas.lendacky@amd.com, vkuznets@redhat.com, bp@alien8.de,
babu.moger@amd.com, Manali Shukla <manali.shukla@amd.com>
Subject: Re: [RFC PATCH v1 2/4] KVM: SVM: Enable Bus lock threshold exit
Date: Wed, 28 Aug 2024 22:14:04 +0530 [thread overview]
Message-ID: <7dc51102-8f41-48bb-89d7-5b82d819671a@amd.com> (raw)
In-Reply-To: <Zr-ubK_e4lAxyt_7@google.com>
>
>> /*
>> * Use nested page tables by default. Note, NPT may get forced off by
>> * svm_hardware_setup() if it's unsupported by hardware or the host kernel.
>> @@ -3231,6 +3234,19 @@ static int invpcid_interception(struct kvm_vcpu *vcpu)
>> return kvm_handle_invpcid(vcpu, type, gva);
>> }
>>
>> +static int bus_lock_exit(struct kvm_vcpu *vcpu)
>> +{
>> + struct vcpu_svm *svm = to_svm(vcpu);
>> +
>> + vcpu->run->exit_reason = KVM_EXIT_X86_BUS_LOCK;
>> + vcpu->run->flags |= KVM_RUN_X86_BUS_LOCK;
>> +
>> + /* Reload the counter again */
>> + svm->vmcb->control.bus_lock_counter = bus_lock_counter;
>> +
>> + return 0;
>> +}
>> +
>> static int (*const svm_exit_handlers[])(struct kvm_vcpu *vcpu) = {
>> [SVM_EXIT_READ_CR0] = cr_interception,
>> [SVM_EXIT_READ_CR3] = cr_interception,
>> @@ -3298,6 +3314,7 @@ static int (*const svm_exit_handlers[])(struct kvm_vcpu *vcpu) = {
>> [SVM_EXIT_CR4_WRITE_TRAP] = cr_trap,
>> [SVM_EXIT_CR8_WRITE_TRAP] = cr_trap,
>> [SVM_EXIT_INVPCID] = invpcid_interception,
>> + [SVM_EXIT_BUS_LOCK] = bus_lock_exit,
>> [SVM_EXIT_NPF] = npf_interception,
>> [SVM_EXIT_RSM] = rsm_interception,
>> [SVM_EXIT_AVIC_INCOMPLETE_IPI] = avic_incomplete_ipi_interception,
>> @@ -4356,6 +4373,27 @@ static void svm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
>
> Why on earth is this in svm_vcpu_after_set_cpuid()? This has nothing to do with
> guest CPUID.>
Sorry, my bad. I will move it to init_vmcb().
>> set_msr_interception(vcpu, svm->msrpm, MSR_IA32_FLUSH_CMD, 0,
>> !!guest_cpuid_has(vcpu, X86_FEATURE_FLUSH_L1D));
>>
>> + if (cpu_feature_enabled(X86_FEATURE_BUS_LOCK_THRESHOLD) &&
>
> This should be a slow path, there's zero reason to check for host support as
> bus_lock_detection_enabled should be allowed if and only if it's supported.>
Agreed. I will remove this check.
>> + vcpu->kvm->arch.bus_lock_detection_enabled) {
>> + svm_set_intercept(svm, INTERCEPT_BUSLOCK);
>> +
>> + /*
>> + * The CPU decrements the bus lock counter every time a bus lock
>> + * is detected. Once the counter reaches zero a VMEXIT_BUSLOCK
>> + * is generated. A value of zero for bus lock counter means a
>> + * VMEXIT_BUSLOCK at every bus lock detection.
>> + *
>> + * Currently, default value for bus_lock_counter is set to 10.
>
> Please don't document the default _here_. Because inevitably this will become
> stale when the default changes.
>
Ack.
>> + * So, the VMEXIT_BUSLOCK is generated after every 10 bus locks
>> + * detected.
>> + */
>> + svm->vmcb->control.bus_lock_counter = bus_lock_counter;
>> + pr_debug("Setting buslock counter to %u\n", bus_lock_counter);
>> + } else {
>> + svm_clr_intercept(svm, INTERCEPT_BUSLOCK);
>> + svm->vmcb->control.bus_lock_counter = 0;
>> + }
>> +
>> if (sev_guest(vcpu->kvm))
>> sev_vcpu_after_set_cpuid(svm);
>>
>> @@ -5149,6 +5187,11 @@ static __init void svm_set_cpu_caps(void)
>> kvm_cpu_cap_set(X86_FEATURE_SVME_ADDR_CHK);
>> }
>>
>> + if (cpu_feature_enabled(X86_FEATURE_BUS_LOCK_THRESHOLD)) {
>> + pr_info("Bus Lock Threashold supported\n");
>> + kvm_caps.has_bus_lock_exit = true;
>> + }
>> +
>> /* CPUID 0x80000008 */
>> if (boot_cpu_has(X86_FEATURE_LS_CFG_SSBD) ||
>> boot_cpu_has(X86_FEATURE_AMD_SSBD))
>> diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
>> index d80a4c6b5a38..2a77232105da 100644
>> --- a/arch/x86/kvm/x86.h
>> +++ b/arch/x86/kvm/x86.h
>> @@ -58,6 +58,7 @@ void kvm_spurious_fault(void);
>> #define KVM_VMX_DEFAULT_PLE_WINDOW_MAX UINT_MAX
>> #define KVM_SVM_DEFAULT_PLE_WINDOW_MAX USHRT_MAX
>> #define KVM_SVM_DEFAULT_PLE_WINDOW 3000
>> +#define KVM_SVM_DEFAULT_BUS_LOCK_COUNTER 10
>
> There's zero reason this needs to be in x86.h. I don't even see a reason to
> have a #define, there's literally one user.
Yeah. I agree. I remove it from V2.
- Manali
next prev parent reply other threads:[~2024-08-28 16:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-09 17:51 [RFC PATCH v1 0/4] Add support for the Bus Lock Threshold Manali Shukla
2024-07-09 17:51 ` [RFC PATCH v1 1/4] x86/cpufeatures: Add CPUID feature bit " Manali Shukla
2024-08-16 19:37 ` Sean Christopherson
2024-08-22 9:43 ` Manali Shukla
2024-08-29 6:48 ` Borislav Petkov
2024-08-30 4:42 ` Sean Christopherson
2024-08-30 8:21 ` Borislav Petkov
2024-09-20 5:53 ` Manali Shukla
2024-07-09 17:51 ` [RFC PATCH v1 2/4] KVM: SVM: Enable Bus lock threshold exit Manali Shukla
2024-08-16 19:54 ` Sean Christopherson
2024-08-24 5:35 ` Manali Shukla
2024-08-26 16:15 ` Sean Christopherson
2024-08-29 6:37 ` Manali Shukla
2024-08-28 16:44 ` Manali Shukla [this message]
2024-07-09 17:51 ` [RFC PATCH v1 3/4] KVM: x86: nSVM: Implement support for nested Bus Lock Threshold Manali Shukla
2024-08-16 20:05 ` Sean Christopherson
2024-08-28 15:52 ` Manali Shukla
2024-08-16 20:14 ` Sean Christopherson
2024-08-29 14:32 ` Manali Shukla
2024-07-09 17:51 ` [RFC PATCH v1 4/4] KVM: selftests: Add bus lock exit test Manali Shukla
2024-08-16 20:21 ` Sean Christopherson
2024-08-26 10:29 ` Manali Shukla
2024-08-26 16:06 ` Sean Christopherson
2024-08-29 9:41 ` Manali Shukla
2024-07-30 4:52 ` [RFC PATCH v1 0/4] Add support for the Bus Lock Threshold Manali Shukla
2024-08-07 3:55 ` Manali Shukla
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=7dc51102-8f41-48bb-89d7-5b82d819671a@amd.com \
--to=manali.shukla@amd.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=vkuznets@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox