* Re: Runtime services support for Xen on ARM [not found] <5641D5F0.5080401@huawei.com> @ 2015-11-10 12:26 ` Stefano Stabellini 2015-11-10 12:36 ` Ian Campbell 2015-11-10 13:12 ` Jan Beulich 0 siblings, 2 replies; 8+ messages in thread From: Stefano Stabellini @ 2015-11-10 12:26 UTC (permalink / raw) To: Shannon Zhao Cc: xen-devel, Ian Campbell, Stefano Stabellini, Shannon Zhao, Christoffer Dall 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? Similarly we don't have an rtc_lock spinlock today and it is not actually needed, but for the sake of keeping the common code common, I would just introduce rtc_lock on ARM too. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Runtime services support for Xen on ARM 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 2015-11-10 13:12 ` Jan Beulich 1 sibling, 2 replies; 8+ messages in thread From: Ian Campbell @ 2015-11-10 12:36 UTC (permalink / raw) To: Stefano Stabellini, Shannon Zhao Cc: xen-devel, Shannon Zhao, Christoffer Dall 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...) Unless there are issues other than kexec with SetVirtualAddressMap which I'm not thinking of now? > Similarly we don't have an rtc_lock spinlock today and it is not > actually needed, but for the sake of keeping the common code common, I > would just introduce rtc_lock on ARM too. Agreed. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Runtime services support for Xen on ARM 2015-11-10 12:36 ` Ian Campbell @ 2015-11-10 14:27 ` Shannon Zhao 2015-11-12 9:06 ` Shannon Zhao 1 sibling, 0 replies; 8+ messages in thread From: Shannon Zhao @ 2015-11-10 14:27 UTC (permalink / raw) To: Ian Campbell, Stefano Stabellini, Shannon Zhao Cc: xen-devel, Christoffer Dall 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...) > Yeah, we could set USE_SET_VIRTUAL_ADDRESS_MAP at this moment, but as you said, it needs to support kexec and make efi_rs_enter() work eventually. So if anyone know this well, please share me your ideas. Thanks very much. > Unless there are issues other than kexec with SetVirtualAddressMap which > I'm not thinking of now? > >> Similarly we don't have an rtc_lock spinlock today and it is not >> actually needed, but for the sake of keeping the common code common, I >> would just introduce rtc_lock on ARM too. > > Agreed. > -- Shannon ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Runtime services support for Xen on ARM 2015-11-10 12:36 ` Ian Campbell 2015-11-10 14:27 ` Shannon Zhao @ 2015-11-12 9:06 ` Shannon Zhao 2015-11-12 11:04 ` Jan Beulich 1 sibling, 1 reply; 8+ messages in thread From: Shannon Zhao @ 2015-11-12 9:06 UTC (permalink / raw) To: Ian Campbell, Stefano Stabellini Cc: xen-devel, Shannon Zhao, Christoffer Dall 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Runtime services support for Xen on ARM 2015-11-12 9:06 ` Shannon Zhao @ 2015-11-12 11:04 ` Jan Beulich 2015-11-12 12:52 ` Shannon Zhao 0 siblings, 1 reply; 8+ messages in thread From: Jan Beulich @ 2015-11-12 11:04 UTC (permalink / raw) To: Shannon Zhao Cc: xen-devel, Shannon Zhao, Ian Campbell, Christoffer Dall, Stefano Stabellini >>> On 12.11.15 at 10:06, <zhaoshenglong@huawei.com> wrote: > 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: You can't just #define that constant and assume things will work: This code is there so far only for documentation purposes. You need to go look what parts of it may have bitrotted. > It fails at below line: > > efi_rs->SetVirtualAddressMap(efi_memmap_size, efi_mdesc_size, > mdesc_ver, efi_memmap); Quite obviously because efi_exit_boot() now sets efi_bs to NULL. Jan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Runtime services support for Xen on ARM 2015-11-12 11:04 ` Jan Beulich @ 2015-11-12 12:52 ` Shannon Zhao 2015-11-12 15:29 ` Jan Beulich 0 siblings, 1 reply; 8+ messages in thread From: Shannon Zhao @ 2015-11-12 12:52 UTC (permalink / raw) To: Jan Beulich, Shannon Zhao Cc: xen-devel, Ian Campbell, Christoffer Dall, Stefano Stabellini On 2015/11/12 19:04, Jan Beulich wrote: >>>> On 12.11.15 at 10:06, <zhaoshenglong@huawei.com> wrote: >> 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: > > You can't just #define that constant and assume things will work: This > code is there so far only for documentation purposes. You need to go > look what parts of it may have bitrotted. > >> It fails at below line: >> >> efi_rs->SetVirtualAddressMap(efi_memmap_size, efi_mdesc_size, >> mdesc_ver, efi_memmap); > > Quite obviously because efi_exit_boot() now sets efi_bs to NULL. > I see in efi_start() there is below code setting efi_bs to NULL. But here it calls efi_rs not efi_bs. I don't understand the relation of them. status = SystemTable->BootServices->ExitBootServices(ImageHandle, map_key); efi_bs = NULL; -- Shannon ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Runtime services support for Xen on ARM 2015-11-12 12:52 ` Shannon Zhao @ 2015-11-12 15:29 ` Jan Beulich 0 siblings, 0 replies; 8+ messages in thread From: Jan Beulich @ 2015-11-12 15:29 UTC (permalink / raw) To: Shannon Zhao, Shannon Zhao Cc: xen-devel, Ian Campbell, Christoffer Dall, Stefano Stabellini >>> On 12.11.15 at 13:52, <shannon.zhao@linaro.org> wrote: > On 2015/11/12 19:04, Jan Beulich wrote: >>>>> On 12.11.15 at 10:06, <zhaoshenglong@huawei.com> wrote: >>> 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: >> >> You can't just #define that constant and assume things will work: This >> code is there so far only for documentation purposes. You need to go >> look what parts of it may have bitrotted. >> >>> It fails at below line: >>> >>> efi_rs->SetVirtualAddressMap(efi_memmap_size, efi_mdesc_size, >>> mdesc_ver, efi_memmap); >> >> Quite obviously because efi_exit_boot() now sets efi_bs to NULL. >> > I see in efi_start() there is below code setting efi_bs to NULL. But > here it calls efi_rs not efi_bs. I don't understand the relation of them. Oh, sorry, my mistake. I guess I'd better not comment on ARM crashes... Jan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Runtime services support for Xen on ARM 2015-11-10 12:26 ` Runtime services support for Xen on ARM Stefano Stabellini 2015-11-10 12:36 ` Ian Campbell @ 2015-11-10 13:12 ` Jan Beulich 1 sibling, 0 replies; 8+ messages in thread From: Jan Beulich @ 2015-11-10 13:12 UTC (permalink / raw) To: Stefano Stabellini, Shannon Zhao Cc: xen-devel, IanCampbell, Christoffer Dall, Shannon Zhao >>> On 10.11.15 at 13:26, <stefano.stabellini@eu.citrix.com> 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? Whether you need to do much on ARM I don't know; doing nothing doesn't seem to be among the options though, as at the very least you need to acquire/release efi_rs_lock. The fact that the code will need refactoring has been well known since the time it got made common. > Similarly we don't have an rtc_lock spinlock today and it is not > actually needed, but for the sake of keeping the common code common, I > would just introduce rtc_lock on ARM too. I think this would better be hidden behind an arch abstraction, doing nothing on ARM. Jan ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-11-12 15:29 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <5641D5F0.5080401@huawei.com> 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 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
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.