All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Roy Franz <roy.franz@linaro.org>
Cc: keir@xen.org, tim@xen.org, stefano.stabellini@citrix.com,
	fu.wei@linaro.org, xen-devel@lists.xen.org
Subject: Re: [PATCH V5 02/15] Move x86 specific funtions/variables to arch header
Date: Mon, 22 Sep 2014 12:31:27 +0100	[thread overview]
Message-ID: <542024AF0200007800036DDB@mail.emea.novell.com> (raw)
In-Reply-To: <1411384185.18331.41.camel@kazak.uk.xensource.com>

>>> On 22.09.14 at 13:09, <Ian.Campbell@citrix.com> wrote:
> On Mon, 2014-09-22 at 11:56 +0100, Jan Beulich wrote:
>> >>> On 22.09.14 at 12:52, <Ian.Campbell@citrix.com> 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

  reply	other threads:[~2014-09-22 11:31 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 22:49 [PATCH V5 00/15] arm64 EFI stub Roy Franz
2014-09-18 22:49 ` [PATCH V5 01/15] move x86 EFI boot/runtime code to common/efi Roy Franz
2014-09-19  8:49   ` Jan Beulich
2014-09-22 10:51     ` Ian Campbell
2014-09-18 22:49 ` [PATCH V5 02/15] Move x86 specific funtions/variables to arch header Roy Franz
2014-09-19  8:37   ` Jan Beulich
2014-09-22 10:52     ` Ian Campbell
2014-09-22 10:56       ` Jan Beulich
2014-09-22 11:09         ` Ian Campbell
2014-09-22 11:31           ` Jan Beulich [this message]
2014-09-22 12:54   ` Jan Beulich
2014-09-23  2:08     ` Roy Franz
2014-09-23 12:24       ` Jan Beulich
2014-09-24  2:35         ` Roy Franz
2014-09-24  8:12           ` Jan Beulich
2014-09-18 22:49 ` [PATCH V5 03/15] create arch functions to allocate memory for and process EFI memory map Roy Franz
2014-09-19  8:47   ` Jan Beulich
2014-09-23  1:14     ` Roy Franz
2014-09-18 22:49 ` [PATCH V5 04/15] Add architecture functions for pre/post ExitBootServices Roy Franz
2014-09-22 12:11   ` Jan Beulich
2014-09-18 22:49 ` [PATCH V5 05/15] Add efi_arch_cfg_file_early/late() to handle arch specific cfg file fields Roy Franz
2014-09-22 12:13   ` Jan Beulich
2014-09-18 22:49 ` [PATCH V5 06/15] Add efi_arch_handle_cmdline() for processing commandline Roy Franz
2014-09-22 12:17   ` Jan Beulich
2014-09-23  1:40     ` Roy Franz
2014-09-23 12:25       ` Jan Beulich
2014-09-24  0:09         ` Roy Franz
2014-09-24  8:13           ` Jan Beulich
2014-09-24  9:33             ` Ian Campbell
2014-09-24 11:34               ` Jan Beulich
2014-09-18 22:49 ` [PATCH V5 07/15] Move x86 specific disk probing code Roy Franz
2014-09-22 12:20   ` Jan Beulich
2014-09-23  1:44     ` Roy Franz
2014-09-18 22:49 ` [PATCH V5 08/15] Create arch functions for console and video init Roy Franz
2014-09-22 12:21   ` Jan Beulich
2014-09-18 22:50 ` [PATCH V5 09/15] Add efi_arch_memory() for arch specific memory setup Roy Franz
2014-09-22 12:24   ` Jan Beulich
2014-09-23  1:45     ` Roy Franz
2014-09-18 22:50 ` [PATCH V5 10/15] Add arch specific module handling to read_file() Roy Franz
2014-09-22 12:44   ` Jan Beulich
2014-09-23  1:57     ` Roy Franz
2014-09-23 12:28       ` Jan Beulich
2014-09-23 12:41         ` Ian Campbell
2014-09-23 12:55           ` Jan Beulich
2014-09-24  1:23       ` Roy Franz
2014-09-24  4:43         ` Roy Franz
2014-09-24  8:18         ` Jan Beulich
2014-09-18 22:50 ` [PATCH V5 11/15] Add several misc. arch functions for EFI boot code Roy Franz
2014-09-22 12:45   ` Jan Beulich
2014-09-18 22:50 ` [PATCH V5 12/15] Add efi_arch_use_config_file() function to control use of config file Roy Franz
2014-09-22 12:48   ` Jan Beulich
2014-09-23  1:59     ` Roy Franz
2014-09-18 22:50 ` [PATCH V5 13/15] add arm64 cache flushing code from linux v3.16 Roy Franz
2014-09-22 10:54   ` Ian Campbell
2014-09-22 23:42     ` Roy Franz
2014-09-23  7:42       ` Ian Campbell
2014-09-18 22:50 ` [PATCH V5 14/15] Update libfdt to v1.4.0 Roy Franz
2014-09-22 11:20   ` Ian Campbell
2014-09-22 23:57     ` Roy Franz
2014-09-23  7:43       ` Ian Campbell
2014-09-18 22:50 ` [PATCH V5 15/15] Add ARM EFI boot support Roy Franz
2014-09-22 11:20   ` Ian Campbell
2014-09-22 23:50     ` Roy Franz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542024AF0200007800036DDB@mail.emea.novell.com \
    --to=jbeulich@suse.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=fu.wei@linaro.org \
    --cc=keir@xen.org \
    --cc=roy.franz@linaro.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.