Message-ID: <sashiko-outbox-208431@kernel.org>
From: sashiko-bot@kernel.org
Subject: Re: [PATCH v3 12/12] KVM: selftests: Test nested VMware backdoor
 routing
Reply-To: sashiko-reviews@lists.linux.dev
To: "Zack Rusin" <zack.rusin@broadcom.com>, kvm@vger.kernel.org
In-Reply-To: <60dbf049b84e8d48da4b4c6138e759d8e2cfb92b.1794374897.git.zack.rusin@broadcom.com>
References: <cover.1794374897.git.zack.rusin@broadcom.com>
 <60dbf049b84e8d48da4b4c6138e759d8e2cfb92b.1794374897.git.zack.rusin@broadcom.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Nov 2026 06:21:53 +0000
Precedence: list

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] KVM: selftests: GUEST_ASSERT() at CPL > 0 in l2_guest_code()
  faults with #GP
--

commit 17432eb224b8266c29f7a0e74dd2c96eb87440ef
Author: Zack Rusin <zack.rusin@broadcom.com>

KVM: selftests: Test nested VMware backdoor routing

This commit adds a KVM selftest verifying how nested VMware backdoor port
accesses from L2 are routed between L0 and L1 across VMX and SVM.

> diff --git a/tools/testing/selftests/kvm/x86/vmware_nested_backdoor_test.=
c b/tools/testing/selftests/kvm/x86/vmware_nested_backdoor_test.c
> new file mode 100644
> index 0000000000000..3d12be7906e0d
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/x86/vmware_nested_backdoor_test.c
> @@ -0,0 +1,223 @@

[ ... ]

> +static void guest_done_handler(struct ex_regs *regs)
> +{
> +	GUEST_DONE();
> +}
> +
> +static void l2_guest_code(void)
> +{
> +	unsigned long rax =3D guest_case.rax;
> +	unsigned long rbx =3D 0;
> +	unsigned long rcx =3D VMPORT_CMD_GETVERSION;
> +	unsigned long rdx =3D guest_case.rdx;
> +
> +	asm volatile("inl %%dx, %%eax"
> +		     : "+a"(rax), "+b"(rbx), "+c"(rcx), "+d"(rdx));
> +	GUEST_ASSERT(guest_case.expect_l0);
> +	asm volatile("int3");
> +}

[Severity: Medium]
Does GUEST_ASSERT(guest_case.expect_l0) in l2_guest_code() cause a false pa=
ss
when a !expect_l0 test case fails to fault on the inl instruction?

l2_guest_code() runs at CPL 2 or CPL 3 with IOPL 0 until int3 transitions to
CPL 0 in guest_done_handler().  If the tested inl does not raise #GP when
guest_case.expect_l0 is false, GUEST_ASSERT() invokes ucall_x86_do_ucall(),
which executes an IN instruction on UCALL_PIO_PORT (0x1000) while still at
CPL > 0.  That port access faults with #GP(0) and exits to L1, where
l1_svm_code() and l1_vmx_code() see GP_VECTOR and report success via
GUEST_DONE() instead of aborting.  Moving the assertion into
guest_done_handler() would run it at CPL 0 where ucalls work.

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/cover.1794374897.gi=
t.zack.rusin@broadcom.com?part=3D12