| Message ID | 20220418090735.3940393-3-wei.chen@arm.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Device tree based NUMA support for Arm - Part#1 | expand |
On Mon, 18 Apr 2022, Wei Chen wrote: > Most of the functions in x86 EFI stub.c can be reused for other > architectures. So we move them to common and keep the x86 specific > function in stub-x86.c. > > Signed-off-by: Wei Chen <wei.chen@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > --- > v1 -> v2: > 1. Drop the copy of stub.c from Arm EFI. > 2. Share common codes of x86 EFI stub for other architectures. > --- > xen/arch/x86/efi/Makefile | 4 +-- > xen/arch/x86/efi/{stub.c => stub-x86.c} | 37 ------------------------ > xen/common/efi/stub.c | 38 +++++++++++++++++++++++++ > 3 files changed, 40 insertions(+), 39 deletions(-) > rename xen/arch/x86/efi/{stub.c => stub-x86.c} (71%) > create mode 100644 xen/common/efi/stub.c > > diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile > index 034ec87895..5ca3a0b4a4 100644 > --- a/xen/arch/x86/efi/Makefile > +++ b/xen/arch/x86/efi/Makefile > @@ -11,8 +11,8 @@ $(obj)/boot.init.o: $(obj)/buildid.o > $(call cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-boundary=4) > $(addprefix $(obj)/,$(EFIOBJ-y)): CFLAGS_stack_boundary := $(cflags-stack-boundary) > > -obj-y := stub.o > +obj-y := stub.o stub-x86.o > obj-$(XEN_BUILD_EFI) := $(filter-out %.init.o,$(EFIOBJ-y)) > obj-bin-$(XEN_BUILD_EFI) := $(filter %.init.o,$(EFIOBJ-y)) > extra-$(XEN_BUILD_EFI) += buildid.o relocs-dummy.o > -nocov-$(XEN_BUILD_EFI) += stub.o > +nocov-$(XEN_BUILD_EFI) += stub.o stub-x86.o > diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c > similarity index 71% > rename from xen/arch/x86/efi/stub.c > rename to xen/arch/x86/efi/stub-x86.c > index 9984932626..2cd5c8d4dc 100644 > --- a/xen/arch/x86/efi/stub.c > +++ b/xen/arch/x86/efi/stub-x86.c > @@ -1,7 +1,5 @@ > #include <xen/efi.h> > -#include <xen/errno.h> > #include <xen/init.h> > -#include <xen/lib.h> > #include <asm/asm_defns.h> > #include <asm/efibind.h> > #include <asm/page.h> > @@ -45,11 +43,6 @@ void __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle, > unreachable(); > } > > -bool efi_enabled(unsigned int feature) > -{ > - return false; > -} > - > void __init efi_init_memory(void) { } > > bool efi_boot_mem_unused(unsigned long *start, unsigned long *end) > @@ -61,33 +54,3 @@ bool efi_boot_mem_unused(unsigned long *start, unsigned long *end) > } > > void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e) { } > - > -bool efi_rs_using_pgtables(void) > -{ > - return false; > -} > - > -unsigned long efi_get_time(void) > -{ > - BUG(); > - return 0; > -} > - > -void efi_halt_system(void) { } > -void efi_reset_system(bool warm) { } > - > -int efi_get_info(uint32_t idx, union xenpf_efi_info *info) > -{ > - return -ENOSYS; > -} > - > -int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *) > - __attribute__((__alias__("efi_get_info"))); > - > -int efi_runtime_call(struct xenpf_efi_runtime_call *op) > -{ > - return -ENOSYS; > -} > - > -int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *) > - __attribute__((__alias__("efi_runtime_call"))); > diff --git a/xen/common/efi/stub.c b/xen/common/efi/stub.c > new file mode 100644 > index 0000000000..6e4f4de9af > --- /dev/null > +++ b/xen/common/efi/stub.c > @@ -0,0 +1,38 @@ > +#include <xen/efi.h> > +#include <xen/errno.h> > +#include <xen/lib.h> > + > +bool efi_enabled(unsigned int feature) > +{ > + return false; > +} > + > +bool efi_rs_using_pgtables(void) > +{ > + return false; > +} > + > +unsigned long efi_get_time(void) > +{ > + BUG(); > + return 0; > +} > + > +void efi_halt_system(void) { } > +void efi_reset_system(bool warm) { } > + > +int efi_get_info(uint32_t idx, union xenpf_efi_info *info) > +{ > + return -ENOSYS; > +} > + > +int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *) > + __attribute__((__alias__("efi_get_info"))); > + > +int efi_runtime_call(struct xenpf_efi_runtime_call *op) > +{ > + return -ENOSYS; > +} > + > +int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *) > + __attribute__((__alias__("efi_runtime_call"))); > -- > 2.25.1 > >
On 18.04.2022 11:07, Wei Chen wrote: > diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c > similarity index 71% > rename from xen/arch/x86/efi/stub.c > rename to xen/arch/x86/efi/stub-x86.c > index 9984932626..2cd5c8d4dc 100644 > --- a/xen/arch/x86/efi/stub.c > +++ b/xen/arch/x86/efi/stub-x86.c I'm not happy to see a file named *x86*.[ch] under x86/. I think the x86 file wants to simply include the common one (and the symlinking be suppressed when a real file already exists). Naming the common file stub-common.c wouldn't help, as a similar anomaly would result. > --- /dev/null > +++ b/xen/common/efi/stub.c > @@ -0,0 +1,38 @@ > +#include <xen/efi.h> > +#include <xen/errno.h> > +#include <xen/lib.h> > + > +bool efi_enabled(unsigned int feature) > +{ > + return false; > +} > + > +bool efi_rs_using_pgtables(void) > +{ > + return false; > +} > + > +unsigned long efi_get_time(void) > +{ > + BUG(); > + return 0; > +} > + > +void efi_halt_system(void) { } > +void efi_reset_system(bool warm) { } > + > +int efi_get_info(uint32_t idx, union xenpf_efi_info *info) > +{ > + return -ENOSYS; > +} > + > +int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *) > + __attribute__((__alias__("efi_get_info"))); I doubt you need this outside of x86. > +int efi_runtime_call(struct xenpf_efi_runtime_call *op) > +{ > + return -ENOSYS; > +} > + > +int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *) > + __attribute__((__alias__("efi_runtime_call"))); Same here. Even for the non-compat variants the need is un-obvious: Are you intending to wire these up anywhere in Arm or common code? This of course is once again pointing out that such code movement would better be done when the new consumers actually appear, such that it's clear why the movement is done - for every individual item. Jan
Hi Jan, On 2022/4/26 16:53, Jan Beulich wrote: > On 18.04.2022 11:07, Wei Chen wrote: >> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c >> similarity index 71% >> rename from xen/arch/x86/efi/stub.c >> rename to xen/arch/x86/efi/stub-x86.c >> index 9984932626..2cd5c8d4dc 100644 >> --- a/xen/arch/x86/efi/stub.c >> +++ b/xen/arch/x86/efi/stub-x86.c > > I'm not happy to see a file named *x86*.[ch] under x86/. I think the > x86 file wants to simply include the common one (and the symlinking > be suppressed when a real file already exists). Naming the common > file stub-common.c wouldn't help, as a similar anomaly would result. > How about using stub-arch.c to indicate this stub file only contains the arch specific contents? However, we cannot predict what link files will be created in this directory in the future. If someone needs to create a stub-arch.c link file in the future, can we solve it at that time? Or do you have any suggestions? >> --- /dev/null >> +++ b/xen/common/efi/stub.c >> @@ -0,0 +1,38 @@ >> +#include <xen/efi.h> >> +#include <xen/errno.h> >> +#include <xen/lib.h> >> + >> +bool efi_enabled(unsigned int feature) >> +{ >> + return false; >> +} >> + >> +bool efi_rs_using_pgtables(void) >> +{ >> + return false; >> +} >> + >> +unsigned long efi_get_time(void) >> +{ >> + BUG(); >> + return 0; >> +} >> + >> +void efi_halt_system(void) { } >> +void efi_reset_system(bool warm) { } >> + >> +int efi_get_info(uint32_t idx, union xenpf_efi_info *info) >> +{ >> + return -ENOSYS; >> +} >> + >> +int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *) >> + __attribute__((__alias__("efi_get_info"))); > > I doubt you need this outside of x86. > >> +int efi_runtime_call(struct xenpf_efi_runtime_call *op) >> +{ >> + return -ENOSYS; >> +} >> + >> +int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *) >> + __attribute__((__alias__("efi_runtime_call"))); > > Same here. > You're correct, I check the code, Arm doesn't need above two compat functions. I will restore them to x86 specific file. > Even for the non-compat variants the need is un-obvious: Are you > intending to wire these up anywhere in Arm or common code? This > of course is once again pointing out that such code movement would > better be done when the new consumers actually appear, such that > it's clear why the movement is done - for every individual item. > Yes, but I didn't deliberately ignore your comment from the last series. I also hesitated for a while when constructing this patch. I felt that this independent work, maybe it would be better to use an independent patch. I will merge patch3 with it, indicating that this movement is to share the EFI stub for Arm. Thanks, Wei Che > Jan >
On 26.04.2022 12:37, Wei Chen wrote: > On 2022/4/26 16:53, Jan Beulich wrote: >> On 18.04.2022 11:07, Wei Chen wrote: >>> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c >>> similarity index 71% >>> rename from xen/arch/x86/efi/stub.c >>> rename to xen/arch/x86/efi/stub-x86.c >>> index 9984932626..2cd5c8d4dc 100644 >>> --- a/xen/arch/x86/efi/stub.c >>> +++ b/xen/arch/x86/efi/stub-x86.c >> >> I'm not happy to see a file named *x86*.[ch] under x86/. I think the >> x86 file wants to simply include the common one (and the symlinking >> be suppressed when a real file already exists). Naming the common >> file stub-common.c wouldn't help, as a similar anomaly would result. >> > > How about using stub-arch.c to indicate this stub file only contains > the arch specific contents? However, we cannot predict what link files > will be created in this directory in the future. If someone needs to > create a stub-arch.c link file in the future, can we solve it at that > time? Or do you have any suggestions? I did provide my suggestion. I do not like stub-arch.c any better than stub-x86.c or stub-common.c. >>> --- /dev/null >>> +++ b/xen/common/efi/stub.c >>> @@ -0,0 +1,38 @@ >>> +#include <xen/efi.h> >>> +#include <xen/errno.h> >>> +#include <xen/lib.h> >>> + >>> +bool efi_enabled(unsigned int feature) >>> +{ >>> + return false; >>> +} >>> + >>> +bool efi_rs_using_pgtables(void) >>> +{ >>> + return false; >>> +} >>> + >>> +unsigned long efi_get_time(void) >>> +{ >>> + BUG(); >>> + return 0; >>> +} >>> + >>> +void efi_halt_system(void) { } >>> +void efi_reset_system(bool warm) { } >>> + >>> +int efi_get_info(uint32_t idx, union xenpf_efi_info *info) >>> +{ >>> + return -ENOSYS; >>> +} >>> + >>> +int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *) >>> + __attribute__((__alias__("efi_get_info"))); >> >> I doubt you need this outside of x86. >> >>> +int efi_runtime_call(struct xenpf_efi_runtime_call *op) >>> +{ >>> + return -ENOSYS; >>> +} >>> + >>> +int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *) >>> + __attribute__((__alias__("efi_runtime_call"))); >> >> Same here. >> > > You're correct, I check the code, Arm doesn't need above two > compat functions. I will restore them to x86 specific file. > >> Even for the non-compat variants the need is un-obvious: Are you >> intending to wire these up anywhere in Arm or common code? This >> of course is once again pointing out that such code movement would >> better be done when the new consumers actually appear, such that >> it's clear why the movement is done - for every individual item. >> > > Yes, but I didn't deliberately ignore your comment from the last > series. I also hesitated for a while when constructing this patch. > I felt that this independent work, maybe it would be better to use > an independent patch. Well, it of course depends on further aspects. If it had been clear that what is moved is actually going to be wired up, this being a standalone patch would be okay-ish. But with this unclear (and, as per above, actually having gone too far) it's imo better to move things as they get re-used. Jan
Hi Jan, > -----Original Message----- > From: Jan Beulich <jbeulich@suse.com> > Sent: 2022年4月26日 22:31 > To: Wei Chen <Wei.Chen@arm.com> > Cc: nd <nd@arm.com>; Andrew Cooper <andrew.cooper3@citrix.com>; Roger Pau > Monné <roger.pau@citrix.com>; Wei Liu <wl@xen.org>; xen- > devel@lists.xenproject.org > Subject: Re: [PATCH v2 02/10] xen/x86: move reusable EFI stub functions > from x86 to common > > On 26.04.2022 12:37, Wei Chen wrote: > > On 2022/4/26 16:53, Jan Beulich wrote: > >> On 18.04.2022 11:07, Wei Chen wrote: > >>> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c > >>> similarity index 71% > >>> rename from xen/arch/x86/efi/stub.c > >>> rename to xen/arch/x86/efi/stub-x86.c > >>> index 9984932626..2cd5c8d4dc 100644 > >>> --- a/xen/arch/x86/efi/stub.c > >>> +++ b/xen/arch/x86/efi/stub-x86.c > >> > >> I'm not happy to see a file named *x86*.[ch] under x86/. I think the > >> x86 file wants to simply include the common one (and the symlinking > >> be suppressed when a real file already exists). Naming the common > >> file stub-common.c wouldn't help, as a similar anomaly would result. > >> > > > > How about using stub-arch.c to indicate this stub file only contains > > the arch specific contents? However, we cannot predict what link files > > will be created in this directory in the future. If someone needs to > > create a stub-arch.c link file in the future, can we solve it at that > > time? Or do you have any suggestions? > > I did provide my suggestion. I do not like stub-arch.c any better than > stub-x86.c or stub-common.c. > With my limited English level, I can only see that you don't like this, but I can't get what you want clearly from your comments. I can only guess: For "x86 file wants to simply include the common one": 1. Did you mean, x86 still keeps it stub.c and includes all its original contents. The common/efi/stub.c link behavior will be ignored, because of x86 has a real stub.c? And common/efi/stub.c still can works for other architectures like Arm whom doesn't have a real stub.c? But in previous version's discussion, I had said I created a stub.c in Arm/efi, and copied Arm required functions from x86/efi/stub.c. But people didn't like it. If my guess is correct, I don't know what is the essential difference between the two approaches. 2. Keeps stub.c in x86/efi, and use it to include common/stub.c. I think this may not be the right understanding, but I can't think of any other understanding. And please forgive my limited reading level again! > >>> --- /dev/null > >>> +++ b/xen/common/efi/stub.c > >>> @@ -0,0 +1,38 @@ > >>> +#include <xen/efi.h> > >>> +#include <xen/errno.h> > >>> +#include <xen/lib.h> > >>> + > >>> +bool efi_enabled(unsigned int feature) > >>> +{ > >>> + return false; > >>> +} > >>> + > >>> +bool efi_rs_using_pgtables(void) > >>> +{ > >>> + return false; > >>> +} > >>> + > >>> +unsigned long efi_get_time(void) > >>> +{ > >>> + BUG(); > >>> + return 0; > >>> +} > >>> + > >>> +void efi_halt_system(void) { } > >>> +void efi_reset_system(bool warm) { } > >>> + > >>> +int efi_get_info(uint32_t idx, union xenpf_efi_info *info) > >>> +{ > >>> + return -ENOSYS; > >>> +} > >>> + > >>> +int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *) > >>> + __attribute__((__alias__("efi_get_info"))); > >> > >> I doubt you need this outside of x86. > >> > >>> +int efi_runtime_call(struct xenpf_efi_runtime_call *op) > >>> +{ > >>> + return -ENOSYS; > >>> +} > >>> + > >>> +int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *) > >>> + __attribute__((__alias__("efi_runtime_call"))); > >> > >> Same here. > >> > > > > You're correct, I check the code, Arm doesn't need above two > > compat functions. I will restore them to x86 specific file. > > > >> Even for the non-compat variants the need is un-obvious: Are you > >> intending to wire these up anywhere in Arm or common code? This > >> of course is once again pointing out that such code movement would > >> better be done when the new consumers actually appear, such that > >> it's clear why the movement is done - for every individual item. > >> > > > > Yes, but I didn't deliberately ignore your comment from the last > > series. I also hesitated for a while when constructing this patch. > > I felt that this independent work, maybe it would be better to use > > an independent patch. > > Well, it of course depends on further aspects. If it had been clear > that what is moved is actually going to be wired up, this being a > standalone patch would be okay-ish. But with this unclear (and, as > per above, actually having gone too far) it's imo better to move > things as they get re-used. > Ok, I understand it now. Thanks, Wei Chen > Jan
On 27.04.2022 04:56, Wei Chen wrote: >> -----Original Message----- >> From: Jan Beulich <jbeulich@suse.com> >> Sent: 2022年4月26日 22:31 >> >> On 26.04.2022 12:37, Wei Chen wrote: >>> On 2022/4/26 16:53, Jan Beulich wrote: >>>> On 18.04.2022 11:07, Wei Chen wrote: >>>>> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c >>>>> similarity index 71% >>>>> rename from xen/arch/x86/efi/stub.c >>>>> rename to xen/arch/x86/efi/stub-x86.c >>>>> index 9984932626..2cd5c8d4dc 100644 >>>>> --- a/xen/arch/x86/efi/stub.c >>>>> +++ b/xen/arch/x86/efi/stub-x86.c >>>> >>>> I'm not happy to see a file named *x86*.[ch] under x86/. I think the >>>> x86 file wants to simply include the common one (and the symlinking >>>> be suppressed when a real file already exists). Naming the common >>>> file stub-common.c wouldn't help, as a similar anomaly would result. >>>> >>> >>> How about using stub-arch.c to indicate this stub file only contains >>> the arch specific contents? However, we cannot predict what link files >>> will be created in this directory in the future. If someone needs to >>> create a stub-arch.c link file in the future, can we solve it at that >>> time? Or do you have any suggestions? >> >> I did provide my suggestion. I do not like stub-arch.c any better than >> stub-x86.c or stub-common.c. >> > > With my limited English level, I can only see that you don't like this, but > I can't get what you want clearly from your comments. I can only guess: > For "x86 file wants to simply include the common one": > 1. Did you mean, x86 still keeps it stub.c and includes all its original > contents. The common/efi/stub.c link behavior will be ignored, because > of x86 has a real stub.c? And common/efi/stub.c still can works for > other architectures like Arm whom doesn't have a real stub.c? > But in previous version's discussion, I had said I created a stub.c in > Arm/efi, and copied Arm required functions from x86/efi/stub.c. But > people didn't like it. If my guess is correct, I don't know what is > the essential difference between the two approaches. > 2. Keeps stub.c in x86/efi, and use it to include common/stub.c. > I think this may not be the right understanding, but I can't think > of any other understanding. 2 is what I've been suggesting. Jan
Hi Jan, On 2022/4/27 13:54, Jan Beulich wrote: > On 27.04.2022 04:56, Wei Chen wrote: >>> -----Original Message----- >>> From: Jan Beulich <jbeulich@suse.com> >>> Sent: 2022年4月26日 22:31 >>> >>> On 26.04.2022 12:37, Wei Chen wrote: >>>> On 2022/4/26 16:53, Jan Beulich wrote: >>>>> On 18.04.2022 11:07, Wei Chen wrote: >>>>>> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c >>>>>> similarity index 71% >>>>>> rename from xen/arch/x86/efi/stub.c >>>>>> rename to xen/arch/x86/efi/stub-x86.c >>>>>> index 9984932626..2cd5c8d4dc 100644 >>>>>> --- a/xen/arch/x86/efi/stub.c >>>>>> +++ b/xen/arch/x86/efi/stub-x86.c >>>>> >>>>> I'm not happy to see a file named *x86*.[ch] under x86/. I think the >>>>> x86 file wants to simply include the common one (and the symlinking >>>>> be suppressed when a real file already exists). Naming the common >>>>> file stub-common.c wouldn't help, as a similar anomaly would result. >>>>> >>>> >>>> How about using stub-arch.c to indicate this stub file only contains >>>> the arch specific contents? However, we cannot predict what link files >>>> will be created in this directory in the future. If someone needs to >>>> create a stub-arch.c link file in the future, can we solve it at that >>>> time? Or do you have any suggestions? >>> >>> I did provide my suggestion. I do not like stub-arch.c any better than >>> stub-x86.c or stub-common.c. >>> >> >> With my limited English level, I can only see that you don't like this, but >> I can't get what you want clearly from your comments. I can only guess: >> For "x86 file wants to simply include the common one": >> 1. Did you mean, x86 still keeps it stub.c and includes all its original >> contents. The common/efi/stub.c link behavior will be ignored, because >> of x86 has a real stub.c? And common/efi/stub.c still can works for >> other architectures like Arm whom doesn't have a real stub.c? >> But in previous version's discussion, I had said I created a stub.c in >> Arm/efi, and copied Arm required functions from x86/efi/stub.c. But >> people didn't like it. If my guess is correct, I don't know what is >> the essential difference between the two approaches. >> 2. Keeps stub.c in x86/efi, and use it to include common/stub.c. >> I think this may not be the right understanding, but I can't think >> of any other understanding. > > 2 is what I've been suggesting. > Got it, thanks! > Jan >
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile index 034ec87895..5ca3a0b4a4 100644 --- a/xen/arch/x86/efi/Makefile +++ b/xen/arch/x86/efi/Makefile @@ -11,8 +11,8 @@ $(obj)/boot.init.o: $(obj)/buildid.o $(call cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-boundary=4) $(addprefix $(obj)/,$(EFIOBJ-y)): CFLAGS_stack_boundary := $(cflags-stack-boundary) -obj-y := stub.o +obj-y := stub.o stub-x86.o obj-$(XEN_BUILD_EFI) := $(filter-out %.init.o,$(EFIOBJ-y)) obj-bin-$(XEN_BUILD_EFI) := $(filter %.init.o,$(EFIOBJ-y)) extra-$(XEN_BUILD_EFI) += buildid.o relocs-dummy.o -nocov-$(XEN_BUILD_EFI) += stub.o +nocov-$(XEN_BUILD_EFI) += stub.o stub-x86.o diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c similarity index 71% rename from xen/arch/x86/efi/stub.c rename to xen/arch/x86/efi/stub-x86.c index 9984932626..2cd5c8d4dc 100644 --- a/xen/arch/x86/efi/stub.c +++ b/xen/arch/x86/efi/stub-x86.c @@ -1,7 +1,5 @@ #include <xen/efi.h> -#include <xen/errno.h> #include <xen/init.h> -#include <xen/lib.h> #include <asm/asm_defns.h> #include <asm/efibind.h> #include <asm/page.h> @@ -45,11 +43,6 @@ void __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle, unreachable(); } -bool efi_enabled(unsigned int feature) -{ - return false; -} - void __init efi_init_memory(void) { } bool efi_boot_mem_unused(unsigned long *start, unsigned long *end) @@ -61,33 +54,3 @@ bool efi_boot_mem_unused(unsigned long *start, unsigned long *end) } void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e) { } - -bool efi_rs_using_pgtables(void) -{ - return false; -} - -unsigned long efi_get_time(void) -{ - BUG(); - return 0; -} - -void efi_halt_system(void) { } -void efi_reset_system(bool warm) { } - -int efi_get_info(uint32_t idx, union xenpf_efi_info *info) -{ - return -ENOSYS; -} - -int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *) - __attribute__((__alias__("efi_get_info"))); - -int efi_runtime_call(struct xenpf_efi_runtime_call *op) -{ - return -ENOSYS; -} - -int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *) - __attribute__((__alias__("efi_runtime_call"))); diff --git a/xen/common/efi/stub.c b/xen/common/efi/stub.c new file mode 100644 index 0000000000..6e4f4de9af --- /dev/null +++ b/xen/common/efi/stub.c @@ -0,0 +1,38 @@ +#include <xen/efi.h> +#include <xen/errno.h> +#include <xen/lib.h> + +bool efi_enabled(unsigned int feature) +{ + return false; +} + +bool efi_rs_using_pgtables(void) +{ + return false; +} + +unsigned long efi_get_time(void) +{ + BUG(); + return 0; +} + +void efi_halt_system(void) { } +void efi_reset_system(bool warm) { } + +int efi_get_info(uint32_t idx, union xenpf_efi_info *info) +{ + return -ENOSYS; +} + +int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *) + __attribute__((__alias__("efi_get_info"))); + +int efi_runtime_call(struct xenpf_efi_runtime_call *op) +{ + return -ENOSYS; +} + +int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *) + __attribute__((__alias__("efi_runtime_call")));
Most of the functions in x86 EFI stub.c can be reused for other architectures. So we move them to common and keep the x86 specific function in stub-x86.c. Signed-off-by: Wei Chen <wei.chen@arm.com> --- v1 -> v2: 1. Drop the copy of stub.c from Arm EFI. 2. Share common codes of x86 EFI stub for other architectures. --- xen/arch/x86/efi/Makefile | 4 +-- xen/arch/x86/efi/{stub.c => stub-x86.c} | 37 ------------------------ xen/common/efi/stub.c | 38 +++++++++++++++++++++++++ 3 files changed, 40 insertions(+), 39 deletions(-) rename xen/arch/x86/efi/{stub.c => stub-x86.c} (71%) create mode 100644 xen/common/efi/stub.c