All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Zack Rusin" <zack.rusin@broadcom.com>, kvm@vger.kernel.org
Subject: Re: [PATCH v3 10/12] KVM: selftests: Test VMware hypercall exits
Date: Wed, 11 Nov 2026 06:23:21 +0000	[thread overview]
Message-ID: <sashiko-outbox-208435@kernel.org> (raw)
In-Reply-To: <e6dfd2e43c8a6ea04fe59b1b5825138ad5523273.1794374897.git.zack.rusin@broadcom.com>

Thank you for your contribution! Sashiko AI review found 4 potential
issues to consider:
- [Low] KVM: selftests: native_hypercall_insn() rejects Zhaoxin VMX CPUs
- [Low] KVM: selftests: vmware_hypercall_test open-codes
  vcpu_run_complete_io()
- [Low] KVM: selftests: exit_reasons_known[] omits
  KVM_EXIT_STRING(VMWARE)
- [Low] KVM: selftests: main() in vmware_hypercall_test duplicates
  (false, true) case
--

commit 54cae967f2b7981d769102ff002d20cd884b4d2d
Author: Zack Rusin <zack.rusin@broadcom.com>

KVM: selftests: Test VMware hypercall exits

This commit adds vmware_hypercall_test to cover KVM_VMWARE_ENABLE_HYPERCALL
and KVM_EXIT_VMWARE, and enables VMware hypercall exits in xen_vmcall_test.

> diff --git a/tools/testing/selftests/kvm/x86/vmware_hypercall_test.c b/tools/testing/selftests/kvm/x86/vmware_hypercall_test.c
> new file mode 100644
> index 0000000000000..d882d3661022b
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/x86/vmware_hypercall_test.c
> @@ -0,0 +1,388 @@
[ ... ]
> +static const u8 *native_hypercall_insn(void)
> +{
> +	if (host_cpu_is_intel)
> +		return vmx_vmcall;
> +	if (host_cpu_is_amd_compatible)
> +		return svm_vmmcall;
> +
> +	TEST_FAIL("VMware hypercall test requires an Intel or AMD-compatible CPU");
> +}

[Severity: Low]
Should native_hypercall_insn() check host_cpu_is_intel_compatible instead
of host_cpu_is_intel?  Zhaoxin CPUs implement VMX and use VMCALL (as
handled in fix_hypercall_test.c and X86_HYPERCALL()), so checking only
host_cpu_is_intel causes the test to hit TEST_FAIL() on Zhaoxin hosts.

[ ... ]

> +static void run_to_vmware_exit(struct vmware_test *test, bool cpl3,
> +			       bool compat)
> +{
> +	test->vcpu->run->kvm_valid_regs = KVM_SYNC_X86_REGS;
> +	vcpu_run(test->vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(test->vcpu, KVM_EXIT_VMWARE);
> +	TEST_ASSERT(test->vcpu->run->kvm_valid_regs & KVM_SYNC_X86_REGS,
> +		    "KVM did not return synchronized GPRs");
> +	assert_hypercall_state(test, cpl3, compat);
> +}

[Severity: Low]
Does exit_reasons_known[] in tools/testing/selftests/kvm/lib/kvm_util.c
need a KVM_EXIT_STRING(VMWARE) entry?  Without it, exit_reason_str()
returns "Unknown" if TEST_ASSERT_KVM_EXIT_REASON() fails on an expected or
unexpected KVM_EXIT_VMWARE exit.

[ ... ]

> +static void test_synchronized_output(bool compat)
> +{
[ ... ]
> +	run->s.regs.regs = expected;
> +	run->kvm_dirty_regs = KVM_SYNC_X86_REGS;
> +	run->immediate_exit = 1;
> +
> +	errno = 0;
> +	ret = __vcpu_run(test.vcpu);
> +	run->immediate_exit = 0;
> +	TEST_ASSERT(ret == -1 && errno == EINTR,
> +		    "Completion with immediate_exit failed: ret=%d errno=%d",
> +		    ret, errno);
[ ... ]
> +}
> +
> +static void test_valid_exception(u32 vector, u32 error_code, u64 address,
> +				 bool dirty_regs)
> +{
[ ... ]
> +	run->immediate_exit = 1;
> +
> +	errno = 0;
> +	ret = __vcpu_run(test.vcpu);
> +	run->immediate_exit = 0;
> +	TEST_ASSERT(ret == -1 && errno == EINTR,
> +		    "Exception completion failed: ret=%d errno=%d", ret, errno);

[Severity: Low]
Can test_synchronized_output() and test_valid_exception() use
vcpu_run_complete_io(test.vcpu) instead of open-coding the immediate_exit
sequence?

[ ... ]

> +int main(int argc, char *argv[])
> +{
[ ... ]
> +	test_synchronized_output(false);
> +	test_synchronized_output(true);
> +
> +	test = create_test(true, false, ARG_RAX);
> +	run_to_vmware_exit(&test, true, false);
> +	destroy_test(&test);
> +
> +	test = create_test(false, true, ARG_RAX);
> +	run_to_vmware_exit(&test, false, true);
> +	destroy_test(&test);

[Severity: Low]
Was the second create_test() / run_to_vmware_exit() block meant to pass
(true, true) instead of (false, true)?  test_synchronized_output(true)
already exercises (cpl3=false, compat=true), whereas (cpl3=true,
compat=true) is not tested.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1794374897.git.zack.rusin@broadcom.com?part=10

  reply	other threads:[~2026-11-11  6:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11  5:59 [PATCH v3 00/12] KVM: Improve VMware guest support Zack Rusin
2026-11-11  5:59 ` [PATCH v3 01/12] KVM: x86/pmu: Honor enable_vmware_backdoor for VMware pseudo-PMCs Zack Rusin
2026-11-12  0:13   ` Jim Mattson
2026-11-11  5:59 ` [PATCH v3 02/12] KVM: x86: Move VMware backdoor support to separate files Zack Rusin
2026-11-12  0:14   ` Jim Mattson
2026-11-11  5:59 ` [PATCH v3 03/12] KVM: x86: Encapsulate VMware backdoor checks Zack Rusin
2026-11-12  0:14   ` Jim Mattson
2026-11-11  5:59 ` [PATCH v3 04/12] KVM: x86: Add CONFIG_KVM_VMWARE Zack Rusin
2026-11-12  0:15   ` Jim Mattson
2026-11-11  5:59 ` [PATCH v3 05/12] KVM: x86: Add a unified VMware capability Zack Rusin
2026-11-12  0:17   ` Jim Mattson
2026-11-11  5:59 ` [PATCH v3 06/12] KVM: x86: Forward VMware hypercalls to userspace Zack Rusin
2026-11-12  0:28   ` Jim Mattson
2026-11-12  5:48     ` Zack Rusin
2026-11-12 18:52   ` Jim Mattson
2026-11-12 20:25   ` David Woodhouse
2026-11-11  5:59 ` [PATCH v3 07/12] KVM: x86: Route nested VMware backdoors to KVM Zack Rusin
2026-11-11  6:36   ` sashiko-bot
2026-11-11  5:59 ` [PATCH v3 08/12] KVM: selftests: Add helpers to run x86 guest code in user mode Zack Rusin
2026-11-11  5:59 ` [PATCH v3 09/12] KVM: selftests: Port VMware backdoor coverage Zack Rusin
2026-11-12 18:36   ` Jim Mattson
2026-11-11  5:59 ` [PATCH v3 10/12] KVM: selftests: Test VMware hypercall exits Zack Rusin
2026-11-11  6:23   ` sashiko-bot [this message]
2026-11-11  6:00 ` [PATCH v3 11/12] KVM: selftests: Test VMware hypercall exits with nested Hyper-V flushes Zack Rusin
2026-11-11  6:00 ` [PATCH v3 12/12] KVM: selftests: Test nested VMware backdoor routing Zack Rusin
2026-11-11  6:21   ` sashiko-bot

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=sashiko-outbox-208435@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=zack.rusin@broadcom.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.