From: Will Deacon <will@kernel.org>
To: Quentin Perret <qperret@google.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Fuad Tabba <tabba@google.com>,
Vincent Donnefort <vdonnefort@google.com>,
Mostafa Saleh <smostafa@google.com>
Subject: Re: [PATCH 17/30] KVM: arm64: Generalise kvm_pgtable_stage2_set_owner()
Date: Fri, 9 Jan 2026 18:46:04 +0000 [thread overview]
Message-ID: <aWFM7NnBkRiM4OQI@willie-the-truck> (raw)
In-Reply-To: <rm55zbvakwmh5ny25bosf3jjiehfubcm2st5q4porsmnffuod5@edygmhqq2ckn>
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
next prev parent reply other threads:[~2026-01-09 18:46 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 15:49 [PATCH 00/30] KVM: arm64: Add support for protected guest memory with pKVM Will Deacon
2026-01-05 15:49 ` [PATCH 01/30] KVM: arm64: Invert KVM_PGTABLE_WALK_HANDLE_FAULT to fix pKVM walkers Will Deacon
2026-01-06 14:33 ` Quentin Perret
2026-01-10 10:22 ` (subset) " Oliver Upton
2026-01-05 15:49 ` [PATCH 02/30] KVM: arm64: Remove redundant 'pgt' pointer checks from MMU notifiers Will Deacon
2026-01-06 14:32 ` Quentin Perret
2026-01-09 14:31 ` Will Deacon
2026-01-09 17:31 ` Will Deacon
2026-01-05 15:49 ` [PATCH 03/30] KVM: arm64: Rename __pkvm_pgtable_stage2_unmap() Will Deacon
2026-01-05 15:49 ` [PATCH 04/30] KVM: arm64: Don't advertise unsupported features for protected guests Will Deacon
2026-01-05 15:49 ` [PATCH 05/30] KVM: arm64: Expose self-hosted debug regs as RAZ/WI " Will Deacon
2026-01-05 15:49 ` [PATCH 06/30] KVM: arm64: Remove pointless is_protected_kvm_enabled() checks from hyp Will Deacon
2026-01-06 14:40 ` Quentin Perret
2026-01-09 14:23 ` Will Deacon
2026-01-05 15:49 ` [PATCH 07/30] KVM: arm64: Ignore MMU notifier callbacks for protected VMs Will Deacon
2026-01-05 15:49 ` [PATCH 08/30] KVM: arm64: Prevent unsupported memslot operations on " Will Deacon
2026-01-05 15:49 ` [PATCH 09/30] KVM: arm64: Split teardown hypercall into two phases Will Deacon
2026-01-05 15:49 ` [PATCH 10/30] KVM: arm64: Introduce __pkvm_host_donate_guest() Will Deacon
2026-01-06 14:48 ` Quentin Perret
2026-01-09 14:30 ` Will Deacon
2026-01-09 15:10 ` Quentin Perret
2026-01-05 15:49 ` [PATCH 11/30] KVM: arm64: Hook up donation hypercall to pkvm_pgtable_stage2_map() Will Deacon
2026-01-05 15:49 ` [PATCH 12/30] KVM: arm64: Handle aborts from protected VMs Will Deacon
2026-01-05 15:49 ` [PATCH 13/30] KVM: arm64: Introduce __pkvm_reclaim_dying_guest_page() Will Deacon
2026-01-06 16:26 ` Vincent Donnefort
2026-01-05 15:49 ` [PATCH 14/30] KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy() Will Deacon
2026-01-06 14:59 ` Quentin Perret
2026-01-09 14:35 ` Will Deacon
2026-01-09 14:57 ` Quentin Perret
2026-01-05 15:49 ` [PATCH 15/30] KVM: arm64: Refactor enter_exception64() Will Deacon
2026-01-05 15:49 ` [PATCH 16/30] KVM: arm64: Inject SIGSEGV on illegal accesses Will Deacon
2026-01-05 15:49 ` [PATCH 17/30] KVM: arm64: Generalise kvm_pgtable_stage2_set_owner() Will Deacon
2026-01-06 15:20 ` Quentin Perret
2026-01-09 18:46 ` Will Deacon [this message]
2026-01-17 0:03 ` Will Deacon
2026-01-05 15:49 ` [PATCH 18/30] KVM: arm64: Introduce host_stage2_set_owner_metadata_locked() Will Deacon
2026-01-05 15:49 ` [PATCH 19/30] KVM: arm64: Annotate guest donations with handle and gfn in host stage-2 Will Deacon
2026-01-06 16:01 ` Fuad Tabba
2026-01-09 14:42 ` Will Deacon
2026-01-12 9:25 ` Fuad Tabba
2026-01-05 15:49 ` [PATCH 20/30] KVM: arm64: Introduce hypercall to force reclaim of a protected page Will Deacon
2026-01-06 15:44 ` Quentin Perret
2026-01-09 17:47 ` Will Deacon
2026-01-05 15:49 ` [PATCH 21/30] KVM: arm64: Reclaim faulting page from pKVM in spurious fault handler Will Deacon
2026-01-05 15:49 ` [PATCH 22/30] KVM: arm64: Return -EFAULT from VCPU_RUN on access to a poisoned pte Will Deacon
2026-01-06 15:54 ` Quentin Perret
2026-01-09 14:57 ` Will Deacon
2026-01-09 15:29 ` Quentin Perret
2026-01-09 17:35 ` Will Deacon
2026-01-05 15:49 ` [PATCH 23/30] KVM: arm64: Add hvc handler at EL2 for hypercalls from protected VMs Will Deacon
2026-01-06 15:52 ` Vincent Donnefort
2026-01-05 15:49 ` [PATCH 24/30] KVM: arm64: Implement the MEM_SHARE hypercall for " Will Deacon
2026-01-06 15:45 ` Vincent Donnefort
2026-01-09 15:01 ` Will Deacon
2026-01-05 15:49 ` [PATCH 25/30] KVM: arm64: Implement the MEM_UNSHARE " Will Deacon
2026-01-06 15:50 ` Vincent Donnefort
2026-01-05 15:49 ` [PATCH 26/30] KVM: arm64: Allow userspace to create protected VMs when pKVM is enabled Will Deacon
2026-01-05 15:49 ` [PATCH 27/30] KVM: arm64: Add some initial documentation for pKVM Will Deacon
2026-01-06 15:59 ` Vincent Donnefort
2026-01-09 15:04 ` Will Deacon
2026-01-05 15:49 ` [PATCH 28/30] KVM: arm64: Extend pKVM page ownership selftests to cover guest donation Will Deacon
2026-01-05 15:49 ` [PATCH 29/30] KVM: arm64: Register 'selftest_vm' in the VM table Will Deacon
2026-01-05 15:49 ` [PATCH 30/30] KVM: arm64: Extend pKVM page ownership selftests to cover forced reclaim Will Deacon
2026-03-13 15:31 ` [PATCH 00/30] KVM: arm64: Add support for protected guest memory with pKVM Mostafa Saleh
2026-04-20 8:02 ` Pavan Kondeti
2026-04-20 10:00 ` Will Deacon
2026-04-20 11:26 ` Pavan Kondeti
2026-04-21 4:15 ` Pavan Kondeti
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=aWFM7NnBkRiM4OQI@willie-the-truck \
--to=will@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=qperret@google.com \
--cc=smostafa@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.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