[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, Dec 16, 2016 at 04:12:00PM +0000, Julien Grall wrote:
> 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/

Fixed for v2.

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

It means On Chip Memories. I can spell it out in v2.

> 
> >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/

Fixed for v2.

> 
> >+         * 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.

Sounds good, I've changed it in code and commit msg for v2.

> 
> >+         * 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.

Yes, I agree.

> 
> 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?

I think it makes sense. We had a discussiong about it a while back ago:
https://lists.xenproject.org/archives/html/xen-devel/2015-05/msg02349.html

The concerns that were raised were wether there could be devices that
could behave badly and possibly giving dom0 access to trig undefined or
unpredictable behavior that could be exploited.

If dom0 accesses devices through a cache, access patterns will change.
In theory it may trig unexpected behaviour in some device. It's hard
to say unless talking about specific chips and implementations.

For example, given dom0 access to a DMA capable device may also achieve
the same. I.e access patterns from DMA units differ from the ones
originating from a CPU using uncached device memory. It could trig
similar kind of errors.

It would be interesting to see a concrete example of a problematic
system.

Best regards,
Edgar

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.