Hi, On 25/09/2019 21:33, Stefano Stabellini wrote: > On Tue, 17 Sep 2019, Julien Grall wrote: >> The 1:1 mapping may clash with other parts of the Xen virtual memory >> layout. At the moment, Xen is handling the clash by only creating a >> mapping to the runtime virtual address before enabling the MMU. >> >> The rest of the mappings (such as the fixmap) will be mapped after the >> MMU is enabled. However, the code doing the mapping is not safe as it >> replace mapping without using the Break-Before-Make sequence. >> >> As the 1:1 mapping can be anywhere in the memory, it is easier to remove >> all the entries added as soon as the 1:1 mapping is not used rather than >> adding the Break-Before-Make sequence everywhere. >> >> It is difficult to track where exactly the 1:1 mapping was created >> without a full rework of create_page_tables(). Instead, introduce a new >> function remove_identity_mapping() will look where is the top-level entry >> for the 1:1 mapping and remove it. >> >> The new function is only called for the boot CPU. Secondary CPUs will >> switch directly to the runtime page-tables so there are no need to >> remove the 1:1 mapping. Note that this still doesn't make the Secondary >> CPUs path safe but it is not making it worst. >> >> Note that the TLB flush sequence is same sequence as described in >> asm-arm/arm32/flushtlb.h with a twist. Per G5-5532 ARM DDI 0487D.a, >> a dsb nsh is sufficient for local flushed. Note the section is from the >> AArch32 Armv8 spec, I wasn't able to find the same exact section in the >> Armv7 spec but this is dotted as local operations only applies to >> non-shareable domain. This was missed while reworking the header and >> therefore a more conservative way were adopted.
I guess the NIT mention in patch #1 should also be fixed here. >> >> Signed-off-by: Julien Grall <julien.gr...@arm.com> > > Reviewed-by: Stefano Stabellini <sstabell...@kernel.org> Thank you for the review. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
