[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Runtime services support for Xen on ARM
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |