RE: [RFC PATCH 0/4] Introducing a common representation of boot info

[Henry Wang <Henry.Wang@xxxxxxx>]

Hi,

It seems that this series has been stale for more than a month, with:

Patch #1 has some discussions in thread.
Patch #2 #3 #4 need some feedback from maintainers.

So sending this email as a gentle reminder. Thanks!

Kind regards,
Henry

> -----Original Message-----
> Subject: [RFC PATCH 0/4] Introducing a common representation of boot info
> 
> This series serves as a proposal to arrive at a common, cross-architecture
> way
> for boot information to be represented during startup. This proposal is
> derived
> from the structures devised to represent hyperlaunch boot information. The
> hyperlaunch boot information structures themselves were based on the boot
> info
> structures used by Arm and dom0less. A significant effort went into ensuring
> the structures are able to support dom0less as well as hyperlaunch.
> 
> Arm and x86 both have arch specific information that must be represented.
> The
> approach here sought to support this through arch structures while
> attempting
> to maximize what was retained in the common structures. For this series, the
> focus was on converting x86 over to the new boot info structures.
> 
> The motivation for this series is due to the fact that the multiboot v1
> structures used by x86 are not sufficient for hyperlaunch. In the previously
> submited hyperlaunch RFC, this was managed by wrapping the mb structures
> inside⎄ the hyperlaunch structures. This at best was could be considered
> crude, but really it was just a hack. One of the goals of hyperlaunch is to
> unify as much as possible with dom0less to remove any unnecessary
> duplication.
> Adopting a common representation for boot information will provide a solid
> foundation for this unification. The added benefit is that in few places this
> will enable an unnecessary arch specific version of logic, XSM for example
> would be able to drop arch specific init functions.
> 
> This series being submitted as an RFC due to,
> * the number of design decisions being made within the series
> * the limited testing able to be completed
> * how extensive the changes will be for x86
> 
> NB: This series is built on top of the v2 patch series, "xsm: refactor and
> optimize policy loading".
> 
> 
> Daniel P. Smith (4):
>   kconfig: allow configuration of maximum modules
>   headers: introduce generalized boot info
>   x86: adopt new boot info structures
>   x86: refactor entrypoints to new boot info
> 
>  xen/arch/Kconfig                          |  12 ++
>  xen/arch/arm/include/asm/setup.h          |   5 +-
>  xen/arch/x86/boot/boot_info32.h           |  81 ++++++++
>  xen/arch/x86/boot/defs.h                  |  17 +-
>  xen/arch/x86/boot/reloc.c                 | 187 +++++++++++------
>  xen/arch/x86/bzimage.c                    |  16 +-
>  xen/arch/x86/cpu/microcode/core.c         | 134 ++++++++-----
>  xen/arch/x86/dom0_build.c                 |  13 +-
>  xen/arch/x86/efi/efi-boot.h               |  96 +++++----
>  xen/arch/x86/guest/xen/pvh-boot.c         |  58 ++++--
>  xen/arch/x86/hvm/dom0_build.c             |  42 ++--
>  xen/arch/x86/include/asm/bootinfo.h       |  45 +++++
>  xen/arch/x86/include/asm/bzimage.h        |   5 +-
>  xen/arch/x86/include/asm/dom0_build.h     |  15 +-
>  xen/arch/x86/include/asm/guest/pvh-boot.h |   6 +-
>  xen/arch/x86/include/asm/setup.h          |  14 +-
>  xen/arch/x86/pv/dom0_build.c              |  34 ++--
>  xen/arch/x86/setup.c                      | 234 ++++++++++++----------
>  xen/common/efi/boot.c                     |   4 +-
>  xen/include/xen/bootinfo.h                | 101 ++++++++++
>  xen/include/xsm/xsm.h                     |  26 ++-
>  xen/xsm/xsm_core.c                        |  22 +-
>  xen/xsm/xsm_policy.c                      |  44 ++--
>  23 files changed, 804 insertions(+), 407 deletions(-)
>  create mode 100644 xen/arch/x86/boot/boot_info32.h
>  create mode 100644 xen/arch/x86/include/asm/bootinfo.h
>  create mode 100644 xen/include/xen/bootinfo.h
> 
> --
> 2.20.1
>