linux-arm-kernel.lists.infradead.org archive mirror
 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:11 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).