Limit support for region overlaps in xlat_tables
authorAntonio Nino Diaz <antonio.ninodiaz@arm.com>
Wed, 30 Mar 2016 14:45:57 +0000 (15:45 +0100)
committerAntonio Nino Diaz <antonio.ninodiaz@arm.com>
Fri, 15 Apr 2016 10:51:44 +0000 (11:51 +0100)
commite1ea9290bba115d103dd8d88d7d39c1b9d4eefe9
treede6d563d2d6c09bc57ea73e33f850717bd4fffb3
parentdf03c6ed42170b900124d75469dad30b95bd5bd1
Limit support for region overlaps in xlat_tables

The only case in which regions can now overlap is if they are
identity mapped or they have the same virtual to physical address
offset (identity mapping is just a particular case of the latter).
They must overlap completely (i.e. one of them must be completely
inside the other one) and not cover the same area.

This allow future enhancements to the xlat_tables library without
having to support unnecessarily complex edge cases.

Outer regions are now sorted by mmap_add_region() before inner
regions with the same base virtual address for consistency: all
regions contained inside another one must be placed after the outer
one in the list.

If an inner region has the same attributes as the outer ones it will
be merged when creating the tables with init_xlation_table(). This
cannot be done as regions are added because there may be cases where
adding a region makes previously mergeable regions no longer
mergeable.

If the attributes of an inner region are different than the outer
region, new pages will be generated regardless of how "restrictive"
they are. For example, RO memory is more restrictive than RW. The
old implementation would give priority to RO if there is an overlap,
the new one doesn't.

NOTE: THIS IS THEORETICALLY A COMPATABILITY BREAK FOR PLATFORMS THAT
USE THE XLAT_TABLES LIBRARY IN AN UNEXPECTED WAY. PLEASE RAISE A
TF-ISSUE IF YOUR PLATFORM IS AFFECTED.

Change-Id: I75fba5cf6db627c2ead70da3feb3cc648c4fe2af
lib/xlat_tables/xlat_tables_common.c