Re: Runtime services support for Xen on ARM

[Shannon Zhao <zhaoshenglong@huawei.com>]

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:

        else
        {
#ifdef USE_SET_VIRTUAL_ADDRESS_MAP
            /* XXX allocate e.g. down from FIXADDR_START */
#endif
            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
ARM?

Thanks,
-- 
Shannon