From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH=v3 1/8] xen: arm: map memory as inner shareable. Date: Mon, 17 Mar 2014 15:17:11 +0000 Message-ID: <532711F7.1070403@linaro.org> References: <1395067981.18221.35.camel@kazak.uk.xensource.com> <1395068010-23344-1-git-send-email-ian.campbell@citrix.com> <53270F7F.9080606@linaro.org> <1395069109.18221.39.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1395069109.18221.39.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/17/2014 03:11 PM, Ian Campbell wrote: > On Mon, 2014-03-17 at 15:06 +0000, Julien Grall wrote: >> Hi Ian, >> >> On 03/17/2014 02:53 PM, Ian Campbell wrote: >>> The inner shareable domain contains all SMP processors, including different >>> clusters (e.g. big.LITTLE). Therefore this is the correct thing to use for Xen >>> memory mappings. The outer shareable domain is for devices on busses which are >>> coherent and barrier-aware (e.g. AMBA4 AXI with ACE). While the system domain >>> is for things behind bridges which are not. >>> >>> One wrinkle is that Normal memory with attributes Inner Non-cacheable, Outer >>> Non-cacheable (which we call BUFFERABLE) must be mapped Outer Shareable on ARM >>> v7. Therefore change the prototype of mfn_to_xen_entry to take the attribute >>> index so we can DTRT. On ARMv8 the sharability is ignored and considered to >>> always be Outer Shareable. >>> >>> Don't adjust the barriers, flushes etc, those remain as they were (which is >>> more than is now required). I'll change those in a later patch. >>> >>> Many thanks to Leif for explaining the difference between Inner- and >>> Outer-Shareable in words of two or less syllables, I hope I've replicated that >>> explanation properly above! >> >> Is there any reason to not modify VTCR_EL2? > > Could do as a future cleanup but I wanted to get Xen's own mappings > sorted first. AFAIU, you are also modifying P2M attributes. In any case: Acked-by: Julien Grall -- Julien Grall