summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/python_version.py
diff options
context:
space:
mode:
authorVincent Donnefort <vdonnefort@google.com>2026-05-21 15:36:24 +0100
committerMarc Zyngier <maz@kernel.org>2026-05-26 16:12:29 +0100
commit6835fbed39bb329744a3f44e8e6a39e24079af10 (patch)
tree48f76bf9a31f4066bf3d6c73ec50e49e988f75bb /tools/lib/python/kdoc/python_version.py
parent5d6919055dec134de3c40167a490f33c74c12581 (diff)
KVM: arm64: Reset page order in pKVM hyp_pool
When a VM fails to initialise after its stage-2 hyp_pool has been initialised, that stage-2 must be torn down entirely. This requires resetting both the refcount and the order of its pages back to 0. Currently, reclaim_pgtable_pages() implicitly resets the page order by allocating the entire pool with order-0 granularity. However, in the VM initialisation error path, the addresses of the donated memory (the PGD) are already known, making it unnecessary to iterate over all pages in the pool. Since the vmemmap page order is a hyp_pool-specific field, leaving a non-zero order on hyp_pool destruction is harmless until another pool attempts to admit the page. Instead of resetting this field during destruction, reset it during pool initialization in hyp_pool_init(). For 'external' pages, we can't trust the order either as they bypass hyp_pool_init(). Since we never coalesce them, enforce order-0 to ensure safe insertion into the pool. This leaves no vmemmap order users outside of hyp_pool. Fixes: 256b4668cd89 ("KVM: arm64: Introduce separate hypercalls for pKVM VM reservation and initialization") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260521143626.1005660-2-vdonnefort@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions