From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] xen/arm64: Use __flush_dcache_area instead of __flush_dcache_all Date: Wed, 15 Oct 2014 09:02:57 +0100 Message-ID: <1413360177.10417.78.camel@citrix.com> References: <20141007104035.GB24725@leverpostej> <20141014092106.GF16598@leverpostej> <1413279323.1497.27.camel@citrix.com> <20141014103233.GH16598@leverpostej> <1413283177.10417.34.camel@citrix.com> <20141014112333.GJ16598@leverpostej> <1413291289.10417.46.camel@citrix.com> <20141014143002.GA1995@leverpostej> <20141014170753.GA4517@leverpostej> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141014170753.GA4517@leverpostej> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mark Rutland Cc: "julien.grall@linaro.org" , "xen-devel@lists.xen.org" , Roy Franz , "suravee.suthikulpanit@amd.com" , "stefano.stabellini@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org On Tue, 2014-10-14 at 18:07 +0100, Mark Rutland wrote: > > Glad I'm not the only one confused :) Getting back to the practical > > side of this, > > I'm thinking I (or Suravee) should update the patch to add the > > flushing of the FDT, > > as this is required for booting with the change to flush_dcache_area(), even if > > the exact mechanism isn't understood. This gets us a more correct and working > > implementation, but not a final/robust implementation. > > On a practical front, yes. > > It would be nice to know if the attributes are actually the problem. > Is it possible to build a UP Xen which maps memory as UEFI does (i.e. > non-shareable)? Or is that problematic? I think it would get to at least the point where you would observe these issues, I'm not sure if/doubt that you would make it to actually booting dom0. Ian.