From: Shivansh Dhiman <shivansh.dhiman@amd.com>
To: Yosry Ahmed <yosry.ahmed@linux.dev>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Kevin Cheng <chengkev@google.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 12/14] x86/svm: Cleanup LBRV tests
Date: Fri, 14 Nov 2025 10:27:07 +0530 [thread overview]
Message-ID: <76608bf1-a47d-4974-8ec9-28e8df7bd43a@amd.com> (raw)
In-Reply-To: <66tns2r4rgrugltijbrxoqyvrpxy6udebpod2udcjnuu6qhsj7@roagtke7znaq>
Hi Yosry,
On 13-11-2025 20:29, Yosry Ahmed wrote:
> On Thu, Nov 13, 2025 at 05:28:11PM +0530, Shivansh Dhiman wrote:
>> Hi Yosry,
>>
>> I tested this on EPYC-Turin and found that some tests seem to be a bit flaky.
>> See below.
>
> Which ones? I was also running the tests on EPYC-Turin.
Most of the nested LBRV tests had this issue. I checked your other patch to fix
this. I tested it and it does fixes it for me. Thanks.
>>
>> On 11-11-2025 04:56, Yosry Ahmed wrote:
>>> @@ -3058,55 +3041,64 @@ u64 dbgctl;
>>>
>>> static void svm_lbrv_test_guest1(void)
>>> {
>>> + u64 from_ip, to_ip;
>>> +
>>> /*
>>> * This guest expects the LBR to be already enabled when it starts,
>>> * it does a branch, and then disables the LBR and then checks.
>>> */
>>> + dbgctl = rdmsr(MSR_IA32_DEBUGCTLMSR);
>>> + TEST_EXPECT_EQ(dbgctl, DEBUGCTLMSR_LBR);
>>
>> This TEST_EXPECT_EQ is run when LBR is enabled, causing it to change last
>> branch. I tried to move it below wrmsr(MSR_IA32_DEBUGCTLMSR, 0) and it works
>> fine that way.
>
> It shouldn't matter though because we execute the branch we care about
> after TEST_EXPECT_EQ(), it's DO_BRANCH(guest_branch0) below. Is it
> possible that the compiler reordered them for some reason?
>
> I liked having the check here because it's easier to follow when the
> checks are done at their logical place rather than delayed after
> wrmsr().
Correct, that should be the natural order.
>>
>>>
>>> DO_BRANCH(guest_branch0);
>>>
>>> - dbgctl = rdmsr(MSR_IA32_DEBUGCTLMSR);
>>> + /* Disable LBR before the checks to avoid changing the last branch */
>>> wrmsr(MSR_IA32_DEBUGCTLMSR, 0);> + dbgctl = rdmsr(MSR_IA32_DEBUGCTLMSR);
>>> + TEST_EXPECT_EQ(dbgctl, 0);
>>>
>>> - if (dbgctl != DEBUGCTLMSR_LBR)
>>> - asm volatile("ud2\n");
>>> - if (rdmsr(MSR_IA32_DEBUGCTLMSR) != 0)
>>> - asm volatile("ud2\n");
>>> + get_lbr_ips(&from_ip, &to_ip);
>>> + TEST_EXPECT_EQ((u64)&guest_branch0_from, from_ip);
>>> + TEST_EXPECT_EQ((u64)&guest_branch0_to, to_ip);
>>>
>>> - GUEST_CHECK_LBR(&guest_branch0_from, &guest_branch0_to);
>>> asm volatile ("vmmcall\n");
>>> }
>>>
>>> static void svm_lbrv_test_guest2(void)
>>> {
>>> + u64 from_ip, to_ip;
>>> +
>>> /*
>>> * This guest expects the LBR to be disabled when it starts,
>>> * enables it, does a branch, disables it and then checks.
>>> */
>>> -
>>> - DO_BRANCH(guest_branch1);
>>> dbgctl = rdmsr(MSR_IA32_DEBUGCTLMSR);
>>> + TEST_EXPECT_EQ(dbgctl, 0);
>>>
>>> - if (dbgctl != 0)
>>> - asm volatile("ud2\n");
>>> + DO_BRANCH(guest_branch1);
>>>
>>> - GUEST_CHECK_LBR(&host_branch2_from, &host_branch2_to);
>>> + get_lbr_ips(&from_ip, &to_ip);
>>> + TEST_EXPECT_EQ((u64)&host_branch2_from, from_ip);
>>> + TEST_EXPECT_EQ((u64)&host_branch2_to, to_ip);
>>>
>>> wrmsr(MSR_IA32_DEBUGCTLMSR, DEBUGCTLMSR_LBR);
>>> dbgctl = rdmsr(MSR_IA32_DEBUGCTLMSR);
>>> + TEST_EXPECT_EQ(dbgctl, DEBUGCTLMSR_LBR);
>>
>> Same thing here as well.
>>
>>> +
>>> DO_BRANCH(guest_branch2);
>>> wrmsr(MSR_IA32_DEBUGCTLMSR, 0);
>>>
>>> - if (dbgctl != DEBUGCTLMSR_LBR)
>>> - asm volatile("ud2\n");
>>> - GUEST_CHECK_LBR(&guest_branch2_from, &guest_branch2_to);
>>> + get_lbr_ips(&from_ip, &to_ip);
>>> + TEST_EXPECT_EQ((u64)&guest_branch2_from, from_ip);
>>> + TEST_EXPECT_EQ((u64)&guest_branch2_to, to_ip);
>>>
>>> asm volatile ("vmmcall\n");
>>> }
>> Reviewed-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
>>
>> Other tests look good to me, and work fine.
>>
>> Tested-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
>
> Thanks!
next prev parent reply other threads:[~2025-11-14 4:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 23:26 [PATCH v3 00/14] Improvements for (nested) SVM testing Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 01/14] scripts: Always return '2' when skipping tests Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 02/14] x86/vmx: Skip vmx_pf_exception_test_fep early if FEP is not available Yosry Ahmed
2025-11-14 0:40 ` Sean Christopherson
2025-11-14 0:47 ` Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 03/14] x86/svm: Cleanup selective cr0 write intercept test Yosry Ahmed
2025-11-12 13:48 ` Manali Shukla
2025-11-10 23:26 ` [PATCH v3 04/14] x86/svm: Move CR0 selective write intercept test near CR3 intercept Yosry Ahmed
2025-11-12 13:52 ` Manali Shukla
2025-11-10 23:26 ` [PATCH v3 05/14] x86/svm: Add FEP helpers for SVM tests Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 06/14] x86/svm: Report unsupported " Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 07/14] x86/svm: Move report_svm_guest() to the top of svm_tests.c Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 08/14] x86/svm: Print SVM test names before running tests Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 09/14] x86/svm: Deflake svm_tsc_scale_test Yosry Ahmed
2025-11-14 0:34 ` Sean Christopherson
2025-11-14 5:46 ` Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 10/14] x86/svm: Generalize and improve selective CR0 write intercept test Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 11/14] x86/svm: Add more selective CR0 write and LMSW test cases Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 12/14] x86/svm: Cleanup LBRV tests Yosry Ahmed
2025-11-13 11:58 ` Shivansh Dhiman
2025-11-13 14:59 ` Yosry Ahmed
2025-11-14 4:57 ` Shivansh Dhiman [this message]
2025-11-14 5:40 ` Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 13/14] x86/svm: Add more LBRV test cases Yosry Ahmed
2025-11-10 23:26 ` [PATCH v3 14/14] x86/svm: Rename VMCB fields to match KVM Yosry Ahmed
2025-11-14 0:40 ` Sean Christopherson
2025-11-11 0:52 ` [PATCH v3 00/14] Improvements for (nested) SVM testing Sean Christopherson
2025-11-11 0:58 ` Yosry Ahmed
2025-11-14 0:46 ` Sean Christopherson
2025-11-14 5:42 ` Yosry Ahmed
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=76608bf1-a47d-4974-8ec9-28e8df7bd43a@amd.com \
--to=shivansh.dhiman@amd.com \
--cc=chengkev@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=yosry.ahmed@linux.dev \
/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