All of lore.kernel.org
 help / color / mirror / Atom feed
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, &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
> >

  reply	other threads:[~2026-09-08  1:44 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
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-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=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 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.