[Xen-devel] [PATCH v2] xen: arm: avoid reusing incorrect mappings when walking the p2m.

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

When we change which PT page we are mapping at a given level then we need to
invalidate any cached mappings further down the tree, otherwise we risk using
them because their offset might match but be based on a different offset
further up the table.

e.g. when remapping first then cur_first_offset and cur_second_offset (which
indicate the currently mapped second and third tables respectively) both become
invalid

Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
---
v2: Also invalidate cur_first_offset when changing cur_first_page.
    Corrected/clarified commit message, this issue isn't really specific to
    superpages, they just happen to expose it.
---
 xen/arch/arm/p2m.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 2f855b5..8ffddac 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -743,6 +743,8 @@ static int apply_p2m_changes(struct domain *d,
                 goto out;
             }
             cur_first_page = p2m_first_level_index(addr);
+            /* Any mapping further down is now invalid */
+            cur_first_offset = cur_second_offset = ~0;
         }
 
         /* We only use a 3 level p2m at the moment, so no level 0,
@@ -765,6 +767,8 @@ static int apply_p2m_changes(struct domain *d,
             if (second) unmap_domain_page(second);
             second = map_domain_page(first[first_table_offset(addr)].p2m.base);
             cur_first_offset = first_table_offset(addr);
+            /* Any mapping further down is now invalid */
+            cur_second_offset = ~0;
         }
         /* else: second already valid */
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel