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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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@xxxxxxxxxx>
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

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