From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v5 19/19] libxl: build a device tree for ARM guests Date: Thu, 14 Nov 2013 12:24:26 +0000 Message-ID: <5284C0FA.8090805@linaro.org> References: <1384366234.29080.8.camel@kazak.uk.xensource.com> <1384366285-29277-19-git-send-email-ian.campbell@citrix.com> <21124.47376.756227.435942@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini , Ian Jackson Cc: tim@xen.org, Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 11/14/2013 12:17 PM, Stefano Stabellini wrote: > On Thu, 14 Nov 2013, Ian Jackson wrote: >> Ian Campbell writes ("[PATCH v5 19/19] libxl: build a device tree for ARM guests"): >>> Uses xc_dom_devicetree_mem which was just added. The call to this needs to be >>> carefully sequenced to be after xc_dom_parse_image (so we can tell which kind >>> of guest we are building, although we don't use this yet) and before >>> xc_dom_mem_init which tries to decide where to place the FDT in guest RAM. >>> >>> Removes libxl_noarch which would only have been used by IA64 after this >>> change. Remove IA64 as part of this patch. >>> >>> There is no attempt to expose this as a configuration setting for the user. >>> >>> Includes a debug hook to dump the dtb to a file for inspection. >> >> Acked-by: Ian Jackson >> >>> TODO: >>> - v7 CPU compat is hardcoded to cortex-a15 -- may need to define something more >>> generic via mach-virt dt bindngs? >> >> I don't have an opinion on this. I hope someone else does :-). > > Wouldn't it be better to use the same cpu compatibility string of the > platform? After all it's the physical cpu that we are time slicing for > the guest: if any quirks are present, it is likely that they are going > to affect the guest too. > /proc doesn't always expose the device tree. It depends on CONFIG_PROC_DEVICETREE: - if it's enabled, you will still need to browse all the directory to find where are the cpus node. But you will need to assume all CPUs are homogeneous. - if it's not enabled, you will need to create a fake one based on, for instance, /proc/cpuinfo. In any case, Linux doesn't seem to care about the cpu compatible string for now. -- Julien Grall