From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v2 0/2] xen: arm: introduce a function and flush dcache while preparing the device tree for Dom0 Date: Wed, 27 Nov 2013 13:50:18 +0000 Message-ID: <5295F89A.9070005@linaro.org> References: <1385463290-31792-1-git-send-email-oleksandr.dmytryshyn@globallogic.com> <1385559013.23112.190.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1385559013.23112.190.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 , Oleksandr Dmytryshyn Cc: Julien Grall , Stefano Stabellini , andrii.anisov@ti.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 11/27/2013 01:30 PM, Ian Campbell wrote: > On Tue, 2013-11-26 at 12:54 +0200, Oleksandr Dmytryshyn wrote: >> Currently we use OMAP5 ES2.0 Panda5 board to work with the hypervisor. >> >> Without flushing dcache the hypervisor couldn't copy the device tree >> correctly when booting the kernel dom0 Image (memory with device tree >> is corrupted). As the result - when we try to load the kernel dom0 >> Image - dom0 hungs frequently. This issue is not reproduced with the >> kernel dom0 zImage because the zImage decompressor code flushes all >> dcache before starting the decompressed kernel Image. When the >> hypervisor loads the kernel image or initrd, this memory region >> isn't corrupted because the hypervisor code flushes the dcache. >> >> Oleksandr Dmytryshyn (2): >> xen: arm: introduce raw_copy_to_guest_flush_dcache() function >> xen: arm: flush dcache while preparing the device tree for Dom0 > > Both of these look good to me as a fix for the dom0 case: > Acked-by: Ian Campbell I'm not convince that is enough to fix dom0 data cache issue. What about the initrd? For the zImage, I took a look to the decompressor code (arch/arm/boot/compressed/head.S) and I didn't see any data cache flush on the first instruction. So the issue can also unlikely happen with the zImage. Instead of introduce a new helper I would prefer modify the existing raw_copy_* helpers to check if we are currently building the domain. -- Julien Grall