[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFCv2 13/15] xen/arm: mm: Use the PMAP helpers in xen_{,un}map_table()
Hi Stefano,
On 15/05/2021 00:35, Stefano Stabellini wrote:
On Sun, 25 Apr 2021, Julien Grall wrote:
From: Julien Grall <jgrall@xxxxxxxxxx>
During early boot, it is not possible to use xen_{,un}map_table()
if the page tables are not residing the Xen binary.
This is a blocker to switch some of the helpers to use xen_pt_update()
as we may need to allocate extra page tables and access them before
the domheap has been initialized (see setup_xenheap_mappings()).
xen_{,un}map_table() are now updated to use the PMAP helpers for early
boot map/unmap. Note that the special case for page-tables residing
in Xen binary has been dropped because it is "complex" and was
only added as a workaround in 8d4f1b8878e0 ("xen/arm: mm: Allow
generic xen page-tables helpers to be called early").
Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx>
In terms of boot stages:
- SYS_STATE_early_boot --> use pmap_map
- greater than SYS_STATE_early_boot --> map_domain_page
While actually pmap would be able to work as far as SYS_STATE_boot, but
we don't need it. Is it worth simplifying it by changing the checks in
the previous patch to be against SYS_STATE_early_boot?
We need to differentiate between when this is used and when PMAP can be
used. The ASSERT() is here to check that the PMAP code is not used
outside of its limit.
In the current implementation, PMAP can be used at any time until we
start bring-up secondary CPUs. So the ASSERT() is correct because
doesn't restrict unnecessarily the use of it.
Note, the code is going to be moved to common code in the next revision.
In any case:
Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Thank you!
Cheers,
--
Julien Grall
|
