Re: [Xen-devel] [PATCH V2 for-4.5] xen/arm64: Use __flush_dcache_area instead of __flush_dcache_all

[Roy Franz <roy.franz@xxxxxxxxxx>]

On Mon, Oct 20, 2014 at 3:59 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2014-10-15 at 20:47 -0700, Roy Franz wrote:
>> +        /* flush dcache covering the FDT updated by EFI boot code */
>> +        mov   x1, 0x200000        /* max size of FDT allowed */
>> +        bl    __flush_dcache_area
>
> Since we are now flushing by VA doesn't this run the risk of overrunning
> the end of the 1:1 map and faulting?
(Dropping Jan from ARM-specific thread...)

Yes it does..


> I think we haven't yet switched to
> our own 2M mapping. Also this will flush for 2M even from a non-2M
> aligned starting point, which might cross the boundary of even a 2M
> mapping. (I think there is probably a related shortcoming in the regular
> head.S, if the DTB is very near the end of a 2M region).
>
> The FDT has a totalsize word (4 bytes from the start). I guess it would
> be simple enough to check the magic number at offset 0 and then read the
> length from offset 4 (don't forget to endian swap), especially since I
> originally thought we would be looking at a full parsing loop (phew!).
> We'd probably also want to clamp the value to 2M or some other sanity
> check value.
>
> Alternatively we might be able to defer the flush until head.S has made
> the mapping in the BOOT_MISC slot, but I'm not 100% sure about that.
>
> Ian.
>
I think the simplest thing to do is to have the C code that calls this
(and just created
the FDT) to pass the size of the FDT to efi_xen_start() so it can
flush the exact amount.
This size is the actual size used (and equal or smaller than the
amount allocated),
so won't overrun the mapping, and should be a sane value.

I should be able to get an updated version out today.

Roy

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