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:54 PM, Ian Campbell wrote:
> 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.

Oh right, I didn't pay attention that we are using different function
for initrd and zImage.

I have acked all the patch series.

-- 
Julien Grall

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