All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	stable@vger.kernel.org, Alexander Potapenko <glider@google.com>
Subject: Re: [PATCH] KVM: arm64: Don't eagerly teardown the vgic on init error
Date: Thu, 24 Oct 2024 19:05:10 +0100	[thread overview]
Message-ID: <86ldyd2x7t.wl-maz@kernel.org> (raw)
In-Reply-To: <3f0918bf-0265-4714-9660-89b75da49859@sirena.org.uk>

On Thu, 24 Oct 2024 17:12:22 +0100,
Mark Brown <broonie@kernel.org> wrote:
> 
> [1  <text/plain; us-ascii (7bit)>]
> On Wed, Oct 09, 2024 at 07:36:03PM +0100, Marc Zyngier wrote:
> > As there is very little ordering in the KVM API, userspace can
> > instanciate a half-baked GIC (missing its memory map, for example)
> > at almost any time.
> 
> The vgic_init selftest has started failing in mainline on multiple
> platforms, with a bisect pointing at this patch which is present there
> as commit df5fd75ee305cb5.  The test reports:
> 
> # selftests: kvm: vgic_init
> # Random seed: 0x6b8b4567
> # Running GIC_v3 tests.
> # ==== Test Assertion Failure ====
> #   lib/kvm_util.c:724: false
> #   pid=1947 tid=1947 errno=5 - Input/output error
> #      1	0x0000000000404edb: __vm_mem_region_delete at kvm_util.c:724 (discriminator 5)
> #      2	0x0000000000405d0b: kvm_vm_free at kvm_util.c:762 (discriminator 12)
> #      3	0x0000000000402d5f: vm_gic_destroy at vgic_init.c:101
> #      4	 (inlined by) test_vcpus_then_vgic at vgic_init.c:368
> #      5	 (inlined by) run_tests at vgic_init.c:720
> #      6	0x0000000000401a6f: main at vgic_init.c:748
> #      7	0x0000ffffa7b37543: ?? ??:0
> #      8	0x0000ffffa7b37617: ?? ??:0
> #      9	0x0000000000401b6f: _start at ??:?
> #   KVM killed/bugged the VM, check the kernel log for clues
> not ok 10 selftests: kvm: vgic_init # exit=254
> 
> which does rather look like a test bug rather than a problem in the
> change itself.

Well, the test tries to do braindead things, and then the test
infrastructure seems surprised that KVM tells it to bugger off...

I can paper over it with this (see below), but frankly, someone who
actually cares about this crap should take a look (and ownership).

	M.

diff --git a/tools/testing/selftests/kvm/aarch64/vgic_init.c b/tools/testing/selftests/kvm/aarch64/vgic_init.c
index b3b5fb0ff0a9..60b076ae85ea 100644
--- a/tools/testing/selftests/kvm/aarch64/vgic_init.c
+++ b/tools/testing/selftests/kvm/aarch64/vgic_init.c
@@ -742,6 +742,8 @@ int main(int ac, char **av)
 	pa_bits = vm_guest_mode_params[VM_MODE_DEFAULT].pa_bits;
 	max_phys_size = 1ULL << pa_bits;
 
+	allow_ioctl_returning_eio = true;
+
 	ret = test_kvm_device(KVM_DEV_TYPE_ARM_VGIC_V3);
 	if (!ret) {
 		pr_info("Running GIC_v3 tests.\n");
diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h
index bc7c242480d6..988c68a77ce3 100644
--- a/tools/testing/selftests/kvm/include/kvm_util.h
+++ b/tools/testing/selftests/kvm/include/kvm_util.h
@@ -298,6 +298,8 @@ static __always_inline void static_assert_is_vm(struct kvm_vm *vm) { }
 	kvm_do_ioctl((vm)->fd, cmd, arg);			\
 })
 
+extern bool allow_ioctl_returning_eio;
+
 /*
  * Assert that a VM or vCPU ioctl() succeeded, with extra magic to detect if
  * the ioctl() failed because KVM killed/bugged the VM.  To detect a dead VM,
@@ -313,6 +315,8 @@ do {											\
 	static_assert_is_vm(vm);							\
 											\
 	if (cond)									\
+		break;									\
+	if (errno == EIO && allow_ioctl_returning_eio)					\
 		break;									\
 											\
 	if (errno == EIO &&								\
diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c
index a2b7df5f1d39..d9834421ab12 100644
--- a/tools/testing/selftests/kvm/lib/kvm_util.c
+++ b/tools/testing/selftests/kvm/lib/kvm_util.c
@@ -25,6 +25,8 @@ static uint32_t last_guest_seed;
 
 static int vcpu_mmap_sz(void);
 
+bool allow_ioctl_returning_eio = false;
+
 int open_path_or_exit(const char *path, int flags)
 {
 	int fd;

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2024-10-24 18:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09 18:36 [PATCH] KVM: arm64: Don't eagerly teardown the vgic on init error Marc Zyngier
2024-10-09 19:25 ` Oliver Upton
2024-10-09 19:36   ` Sean Christopherson
2024-10-09 23:27     ` Oliver Upton
2024-10-09 23:30       ` Oliver Upton
2024-10-10  7:54       ` Marc Zyngier
2024-10-10  8:47         ` Oliver Upton
2024-10-10 12:47           ` Marc Zyngier
2024-10-10 16:47             ` Oliver Upton
2024-10-11 13:20 ` Marc Zyngier
2024-10-24 16:12 ` Mark Brown
2024-10-24 18:05   ` Marc Zyngier [this message]
2024-10-25 10:54     ` Mark Brown
2024-10-25 12:18       ` Eric Auger
2024-10-25 12:59         ` Mark Brown
2024-10-25 13:05           ` Eric Auger
2024-10-25 13:05       ` Marc Zyngier
2024-10-25 13:43         ` Mark Brown

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=86ldyd2x7t.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=broonie@kernel.org \
    --cc=glider@google.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=suzuki.poulose@arm.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.