Re: [PATCH v2 0/2] xen: arm: introduce a function and flush dcache while preparing the device tree for Dom0

[Julien Grall <julien.grall@linaro.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 <ian.campbell@citrix.com>

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