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.
next prev parent 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).