Re: [PATCH 20/37] xen: introduce CONFIG_EFI to stub API for non-EFI architecture

[Julien Grall <julien@xxxxxxx>]

Hi,

On 27/01/2022 09:27, Jan Beulich wrote:
> On 27.01.2022 10:25, Wei Chen wrote:
> > > From: Jan Beulich <jbeulich@xxxxxxxx>
> > > Sent: 2022年1月27日 17:17
> > >
> > > On 27.01.2022 10:09, Wei Chen wrote:
> > > > > From: Jan Beulich <jbeulich@xxxxxxxx>
> > > > > Sent: 2022年1月27日 17:00
> > > > >
> > > > > But you realize we already have such a stub file on x86?
> > > > Yes, we found the redefinition errors that are caused by x86 stub file
> > > > and new macros in stub.h. We had tries to add:
> > > > ifeq ($(XEN_BUILD_EFI),y)
> > > > CFLAGS-y += -DXEN_BUILD_EFI
> > > > XEN_CFLAGS += -DXEN_BUILD_EFI
> > > > endif
> > > > x86/Makefile to gate these new macros, but it seems that we may need
> > > > to change EFI build logic for x86. It will cause more risks for me.
> > > > So I want to introduce a similar stub.c in arch/arm.
> > > While that's perhaps fine, ideally common bits would be common. Iirc
> > > already back at the time I was wondering why stub.c had to be x86-
> > > only.
> > Some dummy functions in stub.c can be shared by arm or other architectures.
> > But some functions like efi_multiboot2 are architecture dependent.
> Right - that's no different from the bulk of the non-stubbed EFI code.
> I don't really mind you making an Arm-specific stub file if there's
> not very much duplication, but it doesn't feel very good. In the end
> it's up to the Arm maintainers anyway.
If the stubs are mostly the same then they should be common rather than 
duplicated.
> x86/Makefile to gate these new macros, but it seems that we may need
> to change EFI build logic for x86. It will cause more risks for me.

But that would be a build risk right? If so, it is quite easy to 
verify/catch it compare to runtime issue.
Cheers,

> Jan
--
Julien Grall