From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shannon Zhao Subject: Re: Runtime services support for Xen on ARM Date: Tue, 10 Nov 2015 22:27:37 +0800 Message-ID: <5641FED9.1090803@linaro.org> References: <5641D5F0.5080401@huawei.com> <1447158988.9407.30.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1447158988.9407.30.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Stefano Stabellini , Shannon Zhao Cc: xen-devel@lists.xensource.com, Christoffer Dall List-Id: xen-devel@lists.xenproject.org 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