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

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

[Edgar E. Iglesias]

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

This patch changes the mapping from non-cached to cached
for mmio-sram nodes that do not have the no-memory-wc property.
This is a hang-over from 4.8 since the mmio-sram patches went
in late in the cycle.

I've explained the rationale in the commit message:
    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.

This was also discussed here:
https://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02412.html

Were we reached the conclusion that we should be using the most relaxed
attributes as long as we don't compromise security.

Since mmio-sram DTS noders have a property (no-memory-wc) to describe
srams with access restrictions, we can select the most relaxed mode
for unrestricted ones.

Cheers,
Edgar

ChangeLog:

v1 -> v2:
* Spell out On Chip Memories (OCMs)
* Avoid dom0 in preference of hardware domains
* Fix spelling of although

Edgar E. Iglesias (1):
  xen/arm: Map mmio-sram nodes as cached memory

 xen/arch/arm/domain_build.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

-- 
2.7.4


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

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

[Edgar E. Iglesias]

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

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@xilinx.com>
---
 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@lists.xen.org
https://lists.xen.org/xen-devel