Re: [PATCH v1 5/5] selftests: KVM: SVM: Add Idle HLT intercept test

On Thu, Mar 07, 2024, Manali Shukla wrote:

From: Manali Shukla Manali.Shukla@amd.com

The Execution of the HLT instruction results in a VMEXIT. Hypervisor observes pending V_INTR and V_NMI events just after the VMEXIT generated by the HLT for the vCPU and causes VM entry to service the pending events. The Idle HLT intercept feature avoids the wasteful VMEXIT during the halt if there are pending V_INTR and V_NMI events for the vCPU.

The selftest for the Idle HLT intercept instruments the above-mentioned scenario.

Signed-off-by: Manali Shukla Manali.Shukla@amd.com

tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/x86_64/svm_idlehlt_test.c | 118 ++++++++++++++++++ 2 files changed, 119 insertions(+) create mode 100644 tools/testing/selftests/kvm/x86_64/svm_idlehlt_test.c

diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile index 492e937fab00..7ad03dc4f35e 100644 --- a/tools/testing/selftests/kvm/Makefile +++ b/tools/testing/selftests/kvm/Makefile @@ -89,6 +89,7 @@ TEST_GEN_PROGS_x86_64 += x86_64/smaller_maxphyaddr_emulation_test TEST_GEN_PROGS_x86_64 += x86_64/smm_test TEST_GEN_PROGS_x86_64 += x86_64/state_test TEST_GEN_PROGS_x86_64 += x86_64/vmx_preemption_timer_test +TEST_GEN_PROGS_x86_64 += x86_64/svm_idlehlt_test

Uber nit, maybe svm_idle_hlt_test? I find "idlehlt" hard to parse.

TEST_GEN_PROGS_x86_64 += x86_64/svm_vmcall_test TEST_GEN_PROGS_x86_64 += x86_64/svm_int_ctl_test TEST_GEN_PROGS_x86_64 += x86_64/svm_nested_shutdown_test diff --git a/tools/testing/selftests/kvm/x86_64/svm_idlehlt_test.c b/tools/testing/selftests/kvm/x86_64/svm_idlehlt_test.c new file mode 100644 index 000000000000..1564511799d4 --- /dev/null +++ b/tools/testing/selftests/kvm/x86_64/svm_idlehlt_test.c @@ -0,0 +1,118 @@ +// SPDX-License-Identifier: GPL-2.0-only +/*

• • svm_idlehalt_test

Please omit this, file comments that state the name of the test inevitably become stale (see above).

• • Copyright (C) 2024 Advanced Micro Devices, Inc.
• • For licencing details see kernel-base/COPYING

This seems gratuitous, doesn't the SPDX stuff take care this?

• • Author:
• • Manali Shukla manali.shukla@amd.com
• */

+#include "kvm_util.h" +#include "svm_util.h" +#include "processor.h" +#include "test_util.h" +#include "apic.h"

+#define VINTR_VECTOR 0x30 +#define NUM_ITERATIONS 100000

What's the runtime? If it's less than a second, then whatever, but if it's at all longer than that, then I'd prefer to use a lower default and make this user- configurable.

+/*

• • Incremented in the VINTR handler. Provides evidence to the sender that the
• • VINR is arrived at the destination.

Evidence is useless if there's no detective looking for it. Yeah, it gets printed out in the end, but in reality, no one is going to look at that.

Rather than read this from the host, just make it a non-volatile bool and assert that it set after every

• */

+static volatile uint64_t vintr_rcvd;

+void verify_apic_base_addr(void) +{

• uint64_t msr = rdmsr(MSR_IA32_APICBASE);
• uint64_t base = GET_APIC_BASE(msr);
• GUEST_ASSERT(base == APIC_DEFAULT_GPA);

+}

+/*

• • The halting guest code instruments the scenario where there is a V_INTR pending
• • event available while hlt instruction is executed. The HLT VM Exit doesn't
• • occur in above-mentioned scenario if the Idle HLT intercept feature is enabled.
• */

+static void halter_guest_code(void)

Just "guest_code()". Yeah, it's a weird generic name, but at this point it's so ubiquitous that it's analogous to main(), i.e. readers know that guest_code() is the entry point. And deviating from that suggests that there is a second vCPU running _other_ guest code (otherwise, why differentiate?), which isn't the case.

+{

• uint32_t icr_val;
• int i;
• verify_apic_base_addr();

Why? The test will fail if the APIC is borked, this is just unnecessary noise that distracts readers.

• xapic_enable();
• icr_val = (APIC_DEST_SELF | APIC_INT_ASSERT | VINTR_VECTOR);
• for (i = 0; i < NUM_ITERATIONS; i++) {

• xapic_write_reg(APIC_ICR, icr_val);
  

• asm volatile("sti; hlt; cli");
  

Please add safe_halt() and cli() helpers in processor.h. And then do:

cli(); xapic_write_reg(APIC_ICR, icr_val); safe_halt();

to guarantee that interrupts are disabled when the IPI is sent. And as above,

GUEST_ASSERT(READ_ONCE(irq_received)); WRITE_ONCE(irq_received, false);

• }
• GUEST_DONE();

+}

+static void guest_vintr_handler(struct ex_regs *regs) +{

• vintr_rcvd++;
• xapic_write_reg(APIC_EOI, 0x30);

EOI is typically written with '0', not the vector, because the legacy EOI register clears the highest ISR vector, not whatever is specified. IIRC, one of the Intel or AMD specs even says to use '0'.

AMD's Specific EOI register does allow targeting a specific vector, but that's not what's being used here.

+}

+int main(int argc, char *argv[]) +{

• struct kvm_vm *vm;
• struct kvm_vcpu *vcpu;
• struct ucall uc;
• uint64_t halt_exits, vintr_exits;
• uint64_t *pvintr_rcvd;
• TEST_REQUIRE(kvm_cpu_has(X86_FEATURE_SVM));

No, this test doesn't require SVM, which is KVM advertising *nested* SVM. This test does require idle-hlt support though...

• /* Check the extension for binary stats */
• TEST_REQUIRE(kvm_has_cap(KVM_CAP_BINARY_STATS_FD));
• vm = vm_create_with_one_vcpu(&vcpu, halter_guest_code);
• vm_init_descriptor_tables(vm);
• vcpu_init_descriptor_tables(vcpu);
• vm_install_exception_handler(vm, VINTR_VECTOR, guest_vintr_handler);
• virt_pg_map(vm, APIC_DEFAULT_GPA, APIC_DEFAULT_GPA);
• vcpu_run(vcpu);
• TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
• halt_exits = vcpu_get_stat(vcpu, "halt_exits");

Is there really no way to get binary stats without having to pass in strings?

• vintr_exits = vcpu_get_stat(vcpu, "irq_window_exits");
• pvintr_rcvd = (uint64_t *)addr_gva2hva(vm, (uint64_t)&vintr_rcvd);
• switch (get_ucall(vcpu, &uc)) {
• case UCALL_ABORT:

• REPORT_GUEST_ASSERT(uc);
  

• /* NOT REACHED */
  

Eh, just put a "break;" here and drop the comment.

• case UCALL_DONE:

• goto done;
  

break;

• default:

• TEST_FAIL("Unknown ucall 0x%lx.", uc.cmd);
  

• }

+done:

• TEST_ASSERT(halt_exits == 0,

So in all honesty, this isn't a very interesting test. It's more of a CPU test than a KVM test. I do think it's worth adding, because why not.

But I'd also like to see a testcase for KVM_X86_DISABLE_EXITS_HLT. It would be a generic test, i.e. not specific to idle-hlt since there is no dependency and the test shouldn't care. I _think_ it would be fairly straightforward: create a VM without an in-kernel APIC (so that HLT exits to userspace), disable HLT interception, send a signal from a different task after some delay, and execute HLT in the guest. Then verify the vCPU exited because of -EINTR and not HLT.

•     "Test Failed:\n"
  

•     "Guest executed VINTR followed by halts: %d times\n"
  

•     "The guest exited due to halt: %ld times and number\n"
  

•     "of vintr exits: %ld and vintr got re-injected: %ld times\n",
  

•     NUM_ITERATIONS, halt_exits, vintr_exits, *pvintr_rcvd);
  

I appreciate the effort to provide more info, but this is way too noisy. If anything, print gory details in a pr_debug() *before* the assert (see below), and then simply do:

TEST_ASSERT_EQ(halt_exits, 0);

• fprintf(stderr,

• "Test Successful:\n"
  

• "Guest executed VINTR followed by halts: %d times\n"
  

• "The guest exited due to halt: %ld times and number\n"
  

• "of vintr exits: %ld and vintr got re-injected: %ld times\n",
  

• NUM_ITERATIONS, halt_exits, vintr_exits, *pvintr_rcvd);
  

And this should be pr_debug(), because no human is going to look at this except when the test isn't working correctly.

• kvm_vm_free(vm);
• return 0;

+}

2.34.1 /pvintr_rcvd