From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH V5 02/15] Move x86 specific funtions/variables to arch header Date: Mon, 22 Sep 2014 12:31:27 +0100 Message-ID: <542024AF0200007800036DDB@mail.emea.novell.com> References: <1411080607-32365-1-git-send-email-roy.franz@linaro.org> <1411080607-32365-3-git-send-email-roy.franz@linaro.org> <541C0772020000780003672C@mail.emea.novell.com> <1411383132.18331.22.camel@kazak.uk.xensource.com> <54201C8E0200007800036D60@mail.emea.novell.com> <1411384185.18331.41.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1411384185.18331.41.camel@kazak.uk.xensource.com> Content-Disposition: inline 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 , Roy Franz Cc: keir@xen.org, tim@xen.org, stefano.stabellini@citrix.com, fu.wei@linaro.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org >>> On 22.09.14 at 13:09, wrote: > On Mon, 2014-09-22 at 11:56 +0100, Jan Beulich wrote: >> >>> On 22.09.14 at 12:52, wrote: >> > On Fri, 2014-09-19 at 09:37 +0100, Jan Beulich wrote: >> >> Hmm, so you're still moving the relocation processing code - why? I >> >> don't recall you having said you're sure you'll not need this on ARM. >> > >> > ARM relocates itself to the top of memory during bringup already. I >> > don't think we need to do it here as well/instead. >> >> There are two relocations (on x86) actually: One (always used) is >> to move the hypervisor image to high physical memory. The other >> (needed under UEFI only) is to relocate the hypervisor from where >> the UEFI loader put it (running in physical mode, virtual and >> physical addresses are the same) to its linked virtual address. Are >> you saying that ARM isn't in need of this? > > Correct, the main ARM entry point (which the UEFI stub calls) takes care > of enabling paging, including handling the move from (potentially > differing) physical to virtual addresses. Ah, right - this really makes the need for doing the extra relocation step x86-64-specific. So Roy, I withdraw my objection then to moving these pieces into arch-specific code. Jan