[PATCH 17/30] KVM: arm64: Generalise kvm_pgtable_stage2_set_owner()

Will Deacon will at kernel.org
Fri Jan 9 10:46:04 PST 2026


On Tue, Jan 06, 2026 at 03:20:15PM +0000, Quentin Perret wrote:
> On Monday 05 Jan 2026 at 15:49:25 (+0000), Will Deacon wrote:
> >  /**
> > - * kvm_pgtable_stage2_set_owner() - Unmap and annotate pages in the IPA space to
> > - *				    track ownership.
> > + * kvm_pgtable_stage2_annotate() - Unmap and annotate pages in the IPA space
> > + *				   to track ownership (and more).
> >   * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
> >   * @addr:	Base intermediate physical address to annotate.
> >   * @size:	Size of the annotated range.
> >   * @mc:		Cache of pre-allocated and zeroed memory from which to allocate
> >   *		page-table pages.
> > - * @owner_id:	Unique identifier for the owner of the page.
> > + * @annotation:	A 62-bit value that will be stored in the page tables.
> > + *		@annotation[0] and @annotation[63] must be 0.
> > + * 		@annotation[62:1] is stored in the page tables.
> >   *
> >   * By default, all page-tables are owned by identifier 0. This function can be
> >   * used to mark portions of the IPA space as owned by other entities. When a
> > @@ -673,8 +678,8 @@ int kvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
> >   *
> >   * Return: 0 on success, negative error code on failure.
> >   */
> > -int kvm_pgtable_stage2_set_owner(struct kvm_pgtable *pgt, u64 addr, u64 size,
> > -				 void *mc, u8 owner_id);
> > +int kvm_pgtable_stage2_annotate(struct kvm_pgtable *pgt, u64 addr, u64 size,
> > +				void *mc, kvm_pte_t annotation);
> 
> While we're on this topic, perhaps we could go one step further and 'type'
> the annotation itself? For instance have a 'type' and 'meta' parameter
> directly at the kvm_pgatble_stage2_annotate() level instead of leaving
> that up to the callers. This would allow to have one place to allocate
> annotation 'types' (donated pages, locked PTE, MMIO guard, ...) and one
> way to serialize/deserialize them. That 'type' would be stored in top 2
> or 3 bits of the PTE for instance, and decoding of the 'meta' field would
> be dependant on the type value. Thoughts?

I don't think a global 'type' space is particularly beneficial, as most
annotations (with the exception of PTE_LOCKED) are specific to the owner
and putting them into a single number space will just waste bits.

But I do like the idea of encoding an annotation type in the pte and
defining those per-owner. I think it would also make some of the code
more robust; for example, I noticed that __pkvm_guest_unshare_host()
isn't putting back the right annotation with my series when I started
looking at implementing your idea.

I'll come back with a diff. It won't be quite what you're suggesting,
but let's see what you think.

Will



More information about the linux-arm-kernel mailing list