All of
 help / color / mirror / Atom feed
From: Shannon Zhao <>
To: Ian Campbell <>,
	Stefano Stabellini <>
	Shannon Zhao <>,
	Christoffer Dall <>
Subject: Re: Runtime services support for Xen on ARM
Date: Thu, 12 Nov 2015 17:06:34 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2015/11/10 20:36, Ian Campbell wrote:
> On Tue, 2015-11-10 at 12:26 +0000, Stefano Stabellini wrote:
>> CC'ing xen-devel and Jan
>> On Tue, 10 Nov 2015, Shannon Zhao wrote:
>>> Hi Stefano,
>>> I'm working on adding Runtime services support at Xen side. Most of
>>> work
>>> is adding the ARM part in xen/common/efi/runtime.c.
>>> There is one problem which block me. That is how to implement
>>> efi_rs_enter() and efi_rs_leave() for ARM, since I think current
>>> implementation is x86 specific and won't work on ARM. Also the
>>> rtc_lock.
>>> Could you give some suggestion? Thanks!
>> efi_rs_enter() and efi_rs_leave() look very PV x86 specific. It is
>> possible that we don't actually need to do anything at all on ARM, aside
>> from refactoring the code. Jan?
> I think these functions derive from the USE_SET_VIRTUAL_ADDRESS_MAP option.
> If that is set we call efi_rs->SetVirtualAddressMap to tell the f/w about
> our virtual address layout and can then call rs directly with no faff.
> Unfortunately SetVirtualAddressMap is incompatible with kexec (I think you
> can only call it once), so we have this USE_SET_VIRTUAL_ADDRESS_MAP option.
> Without USE_SET_VIRTUAL_ADDRESS_MAP we need to switch to a set of page
> tables which are "OK" for calling the runtime services. I'm not sure what
> "OK" means here -- but I suspect it means "1:1" in some part.
> So sadly I think we do _eventually_ need to support this mode (for kexec),
> which would mean quite a bit of refactoring (since the relevant code
> in xen/common/efi/boot.c has some x86-isms).
> But right now, since we do not yet support kexec,  I think we could get the
> ball rolling wrt RS support by setting USE_SET_VIRTUAL_ADDRESS_MAP on ARM
> and dodging the need to make efi_rs_enter() work right now. (IOW make it
> the problem of whomever wants kexec support...)
Hi Ian,

Today I try the way you suggested. Set USE_SET_VIRTUAL_ADDRESS_MAP on
ARM and make a fake efi_rs_enter() and efi_rs_leave(). But when calling
efi_init_memory, it fails with below log:

(XEN) Hypervisor Trap. HSR=0x96000005 EC=0x25 IL=1 Syndrome=0x5
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) ----[ Xen-4.7-unstable  arm64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) PC:     0000000000294564 efi_init_memory+0x4c/0x88
(XEN) LR:     000000000029455c
(XEN) SP:     00000000002bfe00
(XEN) CPSR:   800003c9 MODE:64-bit EL2h (Hypervisor, handler)

(XEN) Xen call trace:
(XEN)    [<0000000000294564>] efi_init_memory+0x4c/0x88 (PC)
(XEN)    [<000000000029455c>] efi_init_memory+0x44/0x88 (LR)
(XEN)    [<000000000028d7c0>] arch_init_memory+0x84/0x8c
(XEN)    [<000000000028f6e4>] start_xen+0xa64/0xca8
(XEN)    [<000000000020060c>] paging+0x84/0xbc

It fails at below line:

    efi_rs->SetVirtualAddressMap(efi_memmap_size, efi_mdesc_size,
                                 mdesc_ver, efi_memmap);

While in efi_init_memory of xen/common/efi/boot.c, I see below words:

            /* XXX allocate e.g. down from FIXADDR_START */
            printk(XENLOG_ERR "No mapping for MFNs %#lx-%#lx\n",
                   smfn, emfn - 1);

I don't understand this function well and what do we need to do here for


  parent reply	other threads:[~2015-11-12  9:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2015-11-10 12:26 ` Runtime services support for Xen on ARM Stefano Stabellini
2015-11-10 12:36   ` Ian Campbell
2015-11-10 14:27     ` Shannon Zhao
2015-11-12  9:06     ` Shannon Zhao [this message]
2015-11-12 11:04       ` Jan Beulich
2015-11-12 12:52         ` Shannon Zhao
2015-11-12 15:29           ` Jan Beulich
2015-11-10 13:12   ` Jan Beulich

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:

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

  git send-email \ \ \ \ \ \ \ \

* 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.