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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Edgar,

On 15/12/16 11:26, Edgar E. Iglesias wrote:
> 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:
> Allthough on chip memories are relatively fast compared to
s/Allthough/Although/

> off-chip memories, large OCMs are still significantly slower
May I ask what does OCMs mean?

> than L1 caches. Depending on the memory, either cached or
> uncached may make most sense.
>
> Also, dom0 may like to use the memory in a cache-coherent way
> to avoid SW managed coherency.
>
> By mapping it cached at S2, we let dom0 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..3a7c1ee 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,
>      },
>      {
> +        /*
> +         * Allthough on chip memories are relatively fast compared to
s/Allthough/Although/

> +         * off-chip memories, large OCMs are still significantly slower
> +         * than L1 caches. Depending on the memory, either cached or
> +         * uncached may make most sense.
> +         *
> +         * Also, dom0 may like to use the memory in a cache-coherent
We prefer to use the term "hardware domain" rather than DOM0 when 
possible in the code.
> +         * way to avoid SW managed coherency.
> +         *
> +         * By mapping it cached at S2, we let dom0 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,
I consider it as the most trusted domain and has other way to mess up 
the platform. So I am fine with this relaxation for the hardware domain 
(AKA DOM0).
However, I have the feeling that we need this kind of relaxation for 
many devices. For instance prefetchable memory BARs for PCI would have 
to be cacheable, same for integrated graphic cards.
I am wondering whether for DOM0 only (*not the other guests), we should 
relax the default stage-2 attribute mapping to p2m_mmio_direct_c.
So we would let DOM0 in charge of the final attribute. This may boost 
the performance of memory access in DOM0.
Any opinions?

>      },
>      { /* sentinel */ },
>  };
Cheers,

--
Julien Grall

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