Re: [Xen-devel] [RFC 02/14] xen/arm: Remove the parameter "attrindx" in copy_paddr

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-03-14 at 18:02 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 03/14/2014 05:14 PM, Ian Campbell wrote:
> > On Wed, 2014-03-12 at 16:15 +0000, Julien Grall wrote:
> >> copy_addr
> > 
> > s/copy_p?addr/copy_from_paddr/ throughout the subject and changelog.
> 
> Right. I will fix it in the next series.
> 
> >>  is only used with BUFFERABLE, there is some place where DEV_SHARED
> >> was used by mistake.
> > 
> > A hangover from flash support or something else?
> 
> I guess, DEV_SHARED was using in few place mainly when Xen is loading a
> small amount of data. Even before this patch, info->load_attr should
> have been used.
> 
> Do you think I need to send a patch for Xen 4.4?

Is it actively harmful or just not ideal?

> >> The parameter "attrindx" can be safely remove and let copy_paddr to map
> >> every page with BUFFERABLE attribute.
> > 
> > What about if e.g. the firmware provides a dtb which is in flash or
> > where the kernel/initrd which it references are in flash. There's
> > nothing inherently wrong with that is there? Maybe BUFFERABLE is still
> > appropriate there for r/o use.
> 
> Even before this patch, Xen was using BUFFERABLE when the kernel/initrd
> is described in the device tree. I don't think it's easily possible to
> know if the range belongs to the RAM or not. Maybe we can use UNCACHE in
> this context?

True. Lets stick with BUFFERABLE (i.e. assume RAM) until someone comes
along with things in flash, then we can actually test things. (or they
never show up and we save ourselves some effort).

Ian.


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