On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for secondary CPUs runtime page-tables is
unnecessary.
All right. Is there an explicit configuration for the shareability and
cacheability used by the page-table walker or is it specified as such in
the Arm Arm?
See the configuration of TCR_EL2, I can mention it.
Also, isn't it possible that CPUs on a different cluster
(big.LITTLE) would have issues with this if the cache could be split
between the two clusters?
I don't understand this... Cache should be coherent when a CPU leaves EL3.
But we already share some bits of the page tables between the processor (see
create_xen_page_tables). So I don't see where there is a possible problem here.
Cheers,
Signed-off-by: Julien Grall <julien.gr...@arm.com>
Reviewed-by: Andrii Anisov <andrii_ani...@epam.com>
---
Changes in v2:
- Add Andrii's reviewed-by
---
xen/arch/arm/mm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index cda2847d00..6db7dda0da 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -769,9 +769,6 @@ int init_secondary_pagetables(int cpu)
write_pte(&first[first_table_offset(DOMHEAP_VIRT_START+i*FIRST_SIZE)], pte);
}
- clean_dcache_va_range(first, PAGE_SIZE);
- clean_dcache_va_range(domheap, DOMHEAP_SECOND_PAGES*PAGE_SIZE);
-
per_cpu(xen_pgtable, cpu) = first;
per_cpu(xen_dommap, cpu) = domheap;
--
2.11.0
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
