All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Itaru Kitayama" <itaru.kitayama@fujitsu.com>
Cc: "Oliver Upton" <oupton@kernel.org>,
	"Marc Zyngier" <maz@kernel.org>,
	kvm@vger.kernel.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH 1/2] KVM: selftest: arm64: Support 5-level paging in stage 1 translation table
Date: Tue, 25 Aug 2026 21:35:33 +0000	[thread overview]
Message-ID: <20260825213534.0D4A41F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260826-arm64-52bit-va-v1-1-14ec98211363@fujitsu.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The page table dump function `pte_dump()` is missing the 'p4d' string for 5-level paging.
--

commit a04aa92b1663291806024b3dd2c32f253a43baf3
Author: Itaru Kitayama <itaru.kitayama@fujitsu.com>

KVM: selftest: arm64: Support 5-level paging in stage 1 translation table

Add p4d_index() for when 5-level paging required, i.e., V52 guest mode
IDs. With the index helper function, _virt_pg_map() handles 5-level
paging case, and aarch64_vcpu_setup() now is aware of the new V52 guest
mode IDs.

> diff --git a/tools/testing/selftests/kvm/lib/arm64/processor.c b/tools/testing/selftests/kvm/lib/arm64/processor.c
> index 01325bf4d36fc..9108e14a9b5be 100644
> --- a/tools/testing/selftests/kvm/lib/arm64/processor.c
> +++ b/tools/testing/selftests/kvm/lib/arm64/processor.c
[ ... ]
> @@ -182,18 +200,35 @@ void virt_arch_pg_map(struct kvm_vm *vm, gva_t gva, gpa_t gpa)
>  
>  u64 *virt_get_pte_hva_at_level(struct kvm_vm *vm, gva_t gva, int level)
>  {
> +	int start_level = 4 - vm->mmu.pgtable_levels;
>  	u64 *ptep;
>  
> +	TEST_ASSERT(level >= start_level && level <= 3,
> +		    "Invalid translation level %d, valid range is %d-3",
> +		    level, start_level);
> +
>  	if (!vm->mmu.pgd_created)
>  		goto unmapped_gva;
>  
>  	ptep = addr_gpa2hva(vm, vm->mmu.pgd) + pgd_index(vm, gva) * 8;
>  	if (!ptep)
>  		goto unmapped_gva;
> -	if (level == 0)
> +	/*
> +	 * Stage-1 translation starts at level -1 for a five-level page
> +	 * table, and at levels 0, 1, or 2 for four-, three-, or two-level
> +	 * page tables, respectively.
> +	 */
> +	if (level == start_level)
>  		return ptep;
>  
>  	switch (vm->mmu.pgtable_levels) {
> +	case 5:
> +		ptep = addr_gpa2hva(vm, pte_addr(vm, *ptep)) + p4d_index(vm, gva) * 8;
> +		if (!ptep)
> +			goto unmapped_gva;
> +		if (level == 0)
> +			break;
> +		/* fall through */
>  	case 4:

[Severity: Low]
Does pte_dump() also need to be updated to handle the new p4d level?

In tools/testing/selftests/kvm/lib/arm64/processor.c:pte_dump():

	static const char * const type[] = { "", "pud", "pmd", "pte" };

With 5-level paging enabled, virt_arch_dump() starts with level 0. The
pte_dump() function will access index 0 and print an empty string instead
of "p4d".

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826-arm64-52bit-va-v1-0-14ec98211363@fujitsu.com?part=1

  reply	other threads:[~2026-08-25 21:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-25 21:18 [PATCH 0/2] 52-bit VA guest mode ID support Itaru Kitayama
2026-08-25 21:18 ` [PATCH 1/2] KVM: selftest: arm64: Support 5-level paging in stage 1 translation table Itaru Kitayama
2026-08-25 21:35   ` sashiko-bot [this message]
2026-09-04  8:38   ` Fuad Tabba
2026-09-08  1:44     ` Itaru Kitayama
2026-09-08  8:08       ` Fuad Tabba
2026-08-25 21:18 ` [PATCH 2/2] KVM: selftests: arm64: Add 52-bit VA guest modes Itaru Kitayama
2026-08-25 21:32   ` sashiko-bot
2026-09-04  8:45   ` Fuad Tabba
2026-09-07 21:24     ` Itaru Kitayama
2026-09-08  8:08       ` Fuad Tabba
2026-09-04  2:55 ` [PATCH 0/2] 52-bit VA guest mode ID support Itaru Kitayama
2026-09-04  8:14 ` Fuad Tabba
2026-09-08  2:18   ` Itaru Kitayama
2026-09-08  7:55     ` Fuad Tabba

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=20260825213534.0D4A41F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=itaru.kitayama@fujitsu.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@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 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.