[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Julien Grall <julien@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: Wei Chen <Wei.Chen@xxxxxxx>
  • Date: Fri, 28 Jan 2022 04:35:28 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LswWmfZr/1thz2Va2j2uD/bXSfofoPGW72BdvvRvi/E=; b=PRpKnYjB3A7ot8huvowofwtl5obiPKC9a0qKOWEp/ByWlwfIiVdSf/12vNfFTPgTiuNSXTdGzUqaaI/wl+gg6Ks3V4RNac4zPHotvCi464ioyQUEIpzmn1QlFSzqoKC4QjhdSZqDtIR8yOsl9fJijOTzXod8vla/Y3VLZVZRRMuORNq6EmhDvSQkCce/IyWKswuu1vntTyad8iaTa/2UZme3ZLr8T9g0neE/hLJ1DUajysWfSJ9KiT91pEvd368KjEHQeLALN4MC6rgP6nGBUxMi0AykPCIK/R2ooN9DNlXAimPXfjSE2awMlEgd0WG0G9d0qMD3gu6cw22JbFUeWw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dZkMfCIMR/dHS3Y9j0GJdA8oyCTLWBxbjcYDcYqEu+WWkTDa0/HWI6hd+DpDB1XUlJN90JTaVnbXrhYbmPT8WefyvfF6ZWzBJVRUrqZCXG5SOO+vCLTaT806VkA63UOP+AnaPQJNqAACZPueXQLsYGGJ2Kop2LGhBCMc9RHk9tdeWHn43zSa4+zUSljvemruyk6Whf8gcgZVVBQjOM3+fgGLJKGC2eij57kCc1NpbG2rj0k+jvJSyI/k3di5smpyzR/IwrQd/9crdC+IIUcBMqMkOR98tSPTwicQuQwQE2foY3EIx1/BBHp9G/dlBpuLzwyDohnFj/Xjks12m++/PQ==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>
  • Delivery-date: Fri, 28 Jan 2022 04:36:00 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHXsHMtR+l18+MmpE6rl/RjSXTBgqx0TXyAgAME0ECAAAH2oIAAA3YAgAAA4bCAAAOtAIAAAa7AgAABegCAAAkkgIABNnUw
  • Thread-topic: [PATCH 20/37] xen: introduce CONFIG_EFI to stub API for non-EFI architecture

Hi Julien,

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Sent: 2022年1月27日 18:01
> To: Jan Beulich <jbeulich@xxxxxxxx>; Wei Chen <Wei.Chen@xxxxxxx>
> Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; sstabellini@xxxxxxxxxx
> Subject: Re: [PATCH 20/37] xen: introduce CONFIG_EFI to stub API for non-
> EFI architecture
> 
> 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.
> 
Risk may be not very accurate word. I mean, I was afraid that my changes
to x86 EFI build would introduce some unforeseen problems to x86. Because
I am not very familiar with that. As you and Jan think it's better, I will
try to do it.

> Cheers,
> 
> >
> > Jan
> >
> 
> --
> Julien Grall

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.