On Tue, Oct 18, 2022 at 3:24 PM Henry Wang <henry.w...@arm.com> wrote:
> Hardware using GICv2 needs to create a P2M mapping of 8KB GICv2 area
> when the domain is created. Considering the worst case of page tables
> which requires 6 P2M pages as the two pages will be consecutive but not
> necessarily in the same L3 page table and keep a buffer, populate 16
> pages as the default value to the P2M pages pool in p2m_init() at the
> domain creation stage to satisfy the GICv2 requirement. For GICv3, the
> above-mentioned P2M mapping is not necessary, but since the allocated
> 16 pages here would not be lost, hence populate these pages
> unconditionally.
>
> With the default 16 P2M pages populated, there would be a case that
> failures would happen in the domain creation with P2M pages already in
> use. To properly free the P2M for this case, firstly support the
> optionally preemption of p2m_teardown(), then call p2m_teardown() and
> p2m_set_allocation(d, 0, NULL) non-preemptively in p2m_final_teardown().
> As non-preemptive p2m_teardown() should only return 0, use a
> BUG_ON to confirm that.
>
> Since p2m_final_teardown() is called either after
> domain_relinquish_resources() where relinquish_p2m_mapping() has been
> called, or from failure path of domain_create()/arch_domain_create()
> where mappings that require p2m_put_l3_page() should never be created,
> relinquish_p2m_mapping() is not added in p2m_final_teardown(), add
> in-code comments to refer this.
>
> Fixes: cbea5a1149ca ("xen/arm: Allocate and free P2M pages from the P2M
> pool")
> Suggested-by: Julien Grall <jgr...@amazon.com>
> Signed-off-by: Henry Wang <henry.w...@arm.com>
>
Henry brought this patch to my attention because it needs a release ack,
but it doesn't seem proper for Henry to be the one to release-ack his own
patches. :-)
I propose that a suitable rule would be:
"If the release manager themselves have submitted a patch which needs a
release ack, then the patch needs a release ack from one of the Committers
who is not involved in the patch."
Given the time-critical nature of this patch, I propose that we adopt the
rule as an expediency now, and we can discuss afterwards whether to make it
permanent.
With that in mind, it looks like this patch is critical for fixing a
release issue; it's in core code, but has also has a lot of scrutiny. So
with that in mind:
Release-acked-by: George Dunlap <george.dun...@citrix.com>
