[PATCH 02/20] KVM: arm64: Propagate host stage-2 annotated entries on block split
Vincent Donnefort
vdonnefort at google.com
Tue Sep 8 03:07:12 PDT 2026
On Mon, Sep 07, 2026 at 02:58:41PM +0100, Wei-Lin Chang wrote:
> On Mon, Aug 03, 2026 at 11:08:46AM +0100, Vincent Donnefort wrote:
>
> [...]
>
> > static void stage2_map_prefault_idmap(const struct kvm_pgtable_visit_ctx *ctx, kvm_pte_t *ptep)
> > {
> > kvm_pte_t block_pte = ctx->old;
> > + bool counted, valid;
> > u64 pa;
> > int i;
> >
> > - if (!kvm_pte_valid(block_pte))
> > + counted = stage2_pte_is_counted(block_pte);
> > + valid = kvm_pte_valid(block_pte);
> > +
> > + if (!valid && !counted)
> > + return;
> > +
> > + /*
> > + * Shared walks not supported: cannot rollback refcounts on break
> > + * failure.
> > + */
> > + if (counted && WARN_ON_ONCE(kvm_pgtable_walk_shared(ctx)))
>
> Doesn't patch 1 also need this shared walk check,
Only the host stage-2 has the IDMAP flag and will run this function.
For the host stage-2, only non valid PTEs and non-RWX PTEs are refcounted.
* non-valid PTEs are skipped in PATCH 1.
* non-RWX PTEs are forced PTE-level.
So there's no risk of hitting a refcounted PTE in this function until PATCH 2.
--
Vincent
>
> > return;
> >
> > pa = ALIGN_DOWN(ctx->addr, kvm_granule_size(ctx->level));
> > for (i = 0; i < PTRS_PER_PTE; ++i, ++ptep, pa += kvm_granule_size(ctx->level + 1)) {
> > - kvm_pte_t pte = kvm_init_valid_leaf_pte(pa, block_pte, ctx->level + 1);
> > + kvm_pte_t pte = valid ?
> > + kvm_init_valid_leaf_pte(pa, block_pte, ctx->level + 1) :
> > + block_pte;
> >
> > /*
> > * Skip ptes in the range being modified by the caller if we're
> > @@ -1053,8 +1066,11 @@ static void stage2_map_prefault_idmap(const struct kvm_pgtable_visit_ctx *ctx, k
> > * that should happen very infrequently.
> > */
> > if ((ctx->level < (KVM_PGTABLE_LAST_LEVEL - 1)) ||
> > - (pa < ctx->addr) || (pa >= ctx->end))
> > + (pa < ctx->addr) || (pa >= ctx->end)) {
> > *ptep = pte;
> > + if (counted)
> > + ctx->mm_ops->get_page(ptep);
>
> and this get_page() ?
>
> Thanks,
> Wei-Lin Chang
>
> [...]
More information about the linux-arm-kernel
mailing list