Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org
Subject: Re: [RFC v3 03/10] KVM: PPC: selftests: add support for powerpc
Date: Fri, 29 May 2026 09:42:28 +0530	[thread overview]
Message-ID: <eciux39v.ritesh.list@gmail.com> (raw)
In-Reply-To: <20260527133246.26D501F000E9@smtp.kernel.org>

sashiko-bot@kernel.org writes:


> commit 4362b48fc35809ad7a74045c726f7ffae0c70ccd
> Author: Nicholas Piggin <npiggin@gmail.com>
>
> KVM: PPC: selftests: add support for powerpc
>
> This commit implements KVM selftests support for powerpc (Book3S-64),
> including ucalls and virtual memory for the radix MMU.
>
>> diff --git a/tools/testing/selftests/kvm/lib/powerpc/processor.c b/tools/testing/selftests/kvm/lib/powerpc/processor.c
>> new file mode 100644
>> index 0000000000000..9846ec26a32aa
>> --- /dev/null
>> +++ b/tools/testing/selftests/kvm/lib/powerpc/processor.c
>
> [ ... ]
>
>> +struct handler {
>> +	void (*fn)(struct ex_regs *regs);
>> +	int trap;
>> +};
>> +
>> +#define NR_HANDLERS	10
>> +static struct handler handlers[NR_HANDLERS];
>
> [Severity: Medium]
> Could this static global array cause state leakage across VMs or race
> conditions in multi-threaded tests?
>
> Since this is defined as a static global on the host rather than a per-VM
> allocation, a new VM will start with a zeroed guest handlers array (from ELF
> loading), but the host's handlers array will retain entries from previous VMs.
>
> This appears to limit the total number of unique handlers that can be installed
> sequentially across all VMs in the entire test process to 10, which would
> eventually result in the "Out of exception handlers" failure below.
>
> Additionally, if multiple threads concurrently create VMs and install exception
> handlers, would they race on this shared host array and sync corrupted state to
> their respective guests?
>

As of now there are no multi-VM tests which creates VMs in parallel.
Also the powerpc exception handler is not used today. It is deferred for
later use when more powerpc specific tests will get added.

If there's ever a need for parallel multi-VM creation, then we can clean
this up.  Even otherwise, I think making it consistent with the other
architectures makes sense (once PowerPC-specific tests get added), so
that too can be deferred until after this base PowerPC KVM selftests
infrastructure lands.

-ritesh

  reply	other threads:[~2026-05-29  4:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27 12:49 [RFC v3 00/10] KVM: selftests: add powerpc support Ritesh Harjani (IBM)
2026-05-27 12:49 ` [RFC v3 01/10] KVM: selftests: Move pgd_created check into virt_pgd_alloc Ritesh Harjani (IBM)
2026-05-27 12:49 ` [RFC v3 02/10] KVM: selftests: Add aligned guest physical page allocator Ritesh Harjani (IBM)
2026-05-27 12:49 ` [RFC v3 03/10] KVM: PPC: selftests: add support for powerpc Ritesh Harjani (IBM)
2026-05-27 13:32   ` sashiko-bot
2026-05-29  4:12     ` Ritesh Harjani [this message]
2026-05-27 12:49 ` [RFC v3 04/10] KVM: PPC: selftests: powerpc enable kvm_create_max_vcpus test Ritesh Harjani (IBM)
2026-05-27 12:49 ` [RFC v3 05/10] KVM: selftests: Print the vcpu_id when KVM_CREATE_VCPU ioctl fails Ritesh Harjani (IBM)
2026-05-27 12:49 ` [RFC v3 06/10] KVM: PPC: selftests: Use u64 instead of uint64_t Ritesh Harjani (IBM)
2026-05-27 12:49 ` [RFC v3 07/10] KVM: PPC: selftests: Use s64 instead of int64_t Ritesh Harjani (IBM)
2026-05-27 12:49 ` [RFC v3 08/10] KVM: PPC: selftests: Use u32 instead of uint32_t Ritesh Harjani (IBM)
2026-05-27 12:49 ` [RFC v3 09/10] KVM: PPC: selftests: Use u8 instead of uint8_t Ritesh Harjani (IBM)
2026-05-27 12:49 ` [RFC v3 10/10] KVM: PPC: selftests: Replace u64 gpa, u64 gva|vaddr with gpa_t and gva_t Ritesh Harjani (IBM)

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=eciux39v.ritesh.list@gmail.com \
    --to=ritesh.list@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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