From: Itaru Kitayama <itaru.kitayama@fujitsu.com>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Shuah Khan <shuah@kernel.org>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org,
Takayuki Okamoto <tokamoto@fujitsu.com>
Subject: Re: [PATCH 1/2] KVM: selftest: arm64: Support 5-level paging in stage 1 translation table
Date: Tue, 8 Sep 2026 10:44:10 +0900 [thread overview]
Message-ID: <ap9oag87vZiuTVer@sm-arm-grace07> (raw)
In-Reply-To: <CA+EHjTy6EH-d=O+dtRdWdTUkS0zkXeW=auxiK6N5Dc-yihrYRw@mail.gmail.com>
Hi Fuad,
On Fri, Sep 04, 2026 at 09:38:39AM +0100, Fuad Tabba wrote:
> Hi Itaru,
>
> The usual subject prefix in the tree is "KVM: arm64: selftests:", for
> this patch and the next one.
Sure. Fix in v2.
> On Tue, 25 Aug 2026 at 22:18, Itaru Kitayama <itaru.kitayama@fujitsu.com> wrote:
> >
> > 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
>
> Only VM_MODE_P52V52_4K has five levels. The 16K and 64K V52 modes get
> four and three, so this is for the 4K granule rather than for V52
> modes as a class.
Yes, understood. Will update the commit log.
>
> ...
>
> > 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)
>
>
> This changes what level means for the existing three-level modes:
> level 0 used to return the top-level entry and now trips the assert,
> level 1 used to return the leaf and now returns the top level. No
> caller in tree asks for either of those two levels, and the new
> numbering matches the architecture.
Yes, as you checked this change won't break current tests, so if you
have better comments I will replace it with yours.
>
> ...
>
> > @@ -321,12 +356,14 @@ void aarch64_vcpu_setup(struct kvm_vcpu *vcpu, struct kvm_vcpu_init *init)
> > case VM_MODE_PXXVYY_4K:
> > TEST_FAIL("AArch64 does not support 4K sized pages "
> > "with ANY-bit physical address ranges");
> > + case VM_MODE_P52V52_64K:
>
> These VM_MODE_ enumerators arrive in patch 2, so this patch does not
> build on its own:
>
> lib/arm64/processor.c:359:7: error: use of undeclared identifier
> 'VM_MODE_P52V52_64K'; did you mean 'VM_MODE_P52V48_64K'?
> lib/arm64/processor.c:360:7: error: duplicate case value 'VM_MODE_P52V48_64K'
>
> There are other build errors from the same cause. Could you move the
> enum values and their vm_guest_mode_string()/vm_guest_mode_params[]
> entries into this patch, or a new one altogether?
Yes, I have rearranged the series to avoid this.
>
> > case VM_MODE_P52V48_64K:
> > case VM_MODE_P48V48_64K:
> > case VM_MODE_P40V48_64K:
> > case VM_MODE_P36V48_64K:
> > tcr_el1 |= TCR_TG0_64K;
> > break;
> > + case VM_MODE_P52V52_16K:
> > case VM_MODE_P52V48_16K:
> > case VM_MODE_P48V48_16K:
> > case VM_MODE_P40V48_16K:
> > @@ -334,6 +371,7 @@ void aarch64_vcpu_setup(struct kvm_vcpu *vcpu, struct kvm_vcpu_init *init)
> > case VM_MODE_P36V47_16K:
> > tcr_el1 |= TCR_TG0_16K;
> > break;
> > + case VM_MODE_P52V52_4K:
> > case VM_MODE_P52V48_4K:
> > case VM_MODE_P48V48_4K:
> > case VM_MODE_P40V48_4K:
> > @@ -348,6 +386,9 @@ void aarch64_vcpu_setup(struct kvm_vcpu *vcpu, struct kvm_vcpu_init *init)
> >
> > /* Configure output size */
> > switch (vm->mode) {
> > + case VM_MODE_P52V52_4K:
> > + case VM_MODE_P52V52_16K:
> > + case VM_MODE_P52V52_64K:
> > case VM_MODE_P52V48_4K:
> > case VM_MODE_P52V48_16K:
> > case VM_MODE_P52V48_64K:
> > @@ -578,6 +619,42 @@ static u32 max_ipa_for_page_size(u32 vm_ipa, u32 gran,
> > return min(vm_ipa, 48U);
> > }
> >
> > +u32 aarch64_get_supported_va_size(void)
>
> This repeats aarch64_get_supported_page_sizes() below it and builds a
> second probe VM one line after the first. Could it take a u32 *va
> out-param, so both ID registers come off the one vCPU?
>
> VARange is the 52-bit VA indicator for the 64K granule only, so a bare
> 52 or 48 reads as granule-independent. The caller in patch 2 only uses
> it for 64K, so nothing is wrong today.
Yes, I've dropped the _va_size() function and instead, expanded a bit
as you suggested the aarch64_get_supported_page_sizes() to check if vcpu
can address upto 52-bit VA space or not (48-bit max).
Thanks,
Itaru.
>
> Cheers,
> /fuad
>
>
> > +{
> > + struct kvm_vcpu_init preferred_init = {};
> > + int kvm_fd, vm_fd, vcpu_fd, err;
> > + u64 val;
> > + u32 va_range;
> > + struct kvm_one_reg reg = {
> > + .id = KVM_ARM64_SYS_REG(SYS_ID_AA64MMFR2_EL1),
> > + .addr = (u64)&val,
> > + };
> > +
> > + kvm_fd = open_kvm_dev_path_or_exit();
> > + vm_fd = __kvm_ioctl(kvm_fd, KVM_CREATE_VM, NULL);
> > + TEST_ASSERT(vm_fd >= 0, KVM_IOCTL_ERROR(KVM_CREATE_VM, vm_fd));
> > +
> > + vcpu_fd = ioctl(vm_fd, KVM_CREATE_VCPU, 0);
> > + TEST_ASSERT(vcpu_fd >= 0, KVM_IOCTL_ERROR(KVM_CREATE_VCPU, vcpu_fd));
> > +
> > + err = ioctl(vm_fd, KVM_ARM_PREFERRED_TARGET, &preferred_init);
> > + TEST_ASSERT(err == 0, KVM_IOCTL_ERROR(KVM_ARM_PREFERRED_TARGET, err));
> > +
> > + err = ioctl(vcpu_fd, KVM_ARM_VCPU_INIT, &preferred_init);
> > + TEST_ASSERT(err == 0, KVM_IOCTL_ERROR(KVM_ARM_VCPU_INIT, err));
> > +
> > + err = ioctl(vcpu_fd, KVM_GET_ONE_REG, ®);
> > + TEST_ASSERT(err == 0, KVM_IOCTL_ERROR(KVM_GET_ONE_REG, err));
> > +
> > + va_range = FIELD_GET(ID_AA64MMFR2_EL1_VARange, val);
> > +
> > + close(vcpu_fd);
> > + close(vm_fd);
> > + close(kvm_fd);
> > +
> > + return va_range >= ID_AA64MMFR2_EL1_VARange_52 ? 52 : 48;
> > +}
> > +
> > void aarch64_get_supported_page_sizes(u32 ipa, u32 *ipa4k,
> > u32 *ipa16k, u32 *ipa64k)
> > {
> >
> > --
> > 2.43.0
> >
next prev parent reply other threads:[~2026-09-08 1:44 UTC|newest]
Thread overview: 13+ 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-09-04 8:38 ` Fuad Tabba
2026-09-08 1:44 ` Itaru Kitayama [this message]
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-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=ap9oag87vZiuTVer@sm-arm-grace07 \
--to=itaru.kitayama@fujitsu.com \
--cc=fuad.tabba@linux.dev \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=pbonzini@redhat.com \
--cc=seiden@linux.ibm.com \
--cc=shuah@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tokamoto@fujitsu.com \
--cc=yuzenghui@huawei.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