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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-11-27 at 13:50 +0000, Julien Grall wrote:
> 
> 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.

The zImage and initrd are both loaded with copy_from_paddr, which does
the appropriate flushing.

> Instead of introduce a new helper I would prefer modify the existing 
> raw_copy_* helpers to check if we are currently building the domain.

Given the above I don't think that is necessary or correct.

Ian.



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