From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC 02/14] xen/arm: Remove the parameter "attrindx" in copy_paddr Date: Fri, 14 Mar 2014 18:02:05 +0000 Message-ID: <5323441D.3080404@linaro.org> References: <1394640969-25583-1-git-send-email-julien.grall@linaro.org> <1394640969-25583-3-git-send-email-julien.grall@linaro.org> <1394817258.6442.173.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WOWQq-0002Fp-V7 for xen-devel@lists.xenproject.org; Fri, 14 Mar 2014 18:02:09 +0000 Received: by mail-ee0-f44.google.com with SMTP id e49so1669454eek.31 for ; Fri, 14 Mar 2014 11:02:07 -0700 (PDT) In-Reply-To: <1394817258.6442.173.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org 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? >> 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? Regards, -- Julien Grall