[Xen-devel] [PATCH v2 1/1] xen/arm: Map mmio-sram nodes as cached memory

["Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxx>]

From: "Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxxx>

Relax the mapping of mmio-sram nodes that do not set the
no-memory-wc property to cached normal memory.

Rationale:
Although on chip memories are relatively fast compared to
off-chip memories, large on chip memories are still
significantly slower than L1 caches. Depending on the
memory, either cached or uncached may make most sense.

Also, hardware domains may like to use the memory in a
cache-coherent way to avoid SW managed coherency.

By mapping it cached at S2, we let hardware domains select
cacheability via S1 mappings.

Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xxxxxxxxxx>
---
 xen/arch/arm/domain_build.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 07b868d..08646b8 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -56,8 +56,20 @@ static const struct dt_device_match dev_map_attrs[] 
__initconst =
         .data = (void *) (uintptr_t) p2m_mmio_direct_dev,
     },
     {
+        /*
+         * Although on chip memories are relatively fast compared to
+         * off-chip memories, large on chip memories are still
+         * significantly slower than L1 caches. Depending on the
+         * memory, either cached or uncached may make most sense.
+         *
+         * Also, hardware domains may like to use the memory in a
+         * cache-coherent way to avoid SW managed coherency.
+         *
+         * By mapping it cached at S2, we let hardware domains select
+         * cacheability via S1 mappings.
+         */
         __DT_MATCH_COMPATIBLE("mmio-sram"),
-        .data = (void *) (uintptr_t) p2m_mmio_direct_nc,
+        .data = (void *) (uintptr_t) p2m_mmio_direct_c,
     },
     { /* sentinel */ },
 };
-- 
2.7.4


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