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
> 

On 06.07.2022 09:30, Henry Wang wrote:
> 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!

As a general remark: RFCs, at least in my view, take lower priority than
"ordinary" patch submissions (and other work). I, for example, have this
and other on my "to look at" list, but I can't really predict when all
higher priority items would have been dealt with. It's the sad reality
that in effect this often means RFCs won't be looked at at all. One of
the many unfortunate effects of our limited review bandwidth.

Jan

Hi Jan,

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Subject: Re: [RFC PATCH 0/4] Introducing a common representation of boot
> info
> 
> On 06.07.2022 09:30, Henry Wang wrote:
> > 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!
> 
> As a general remark: RFCs, at least in my view, take lower priority than
> "ordinary" patch submissions (and other work). I, for example, have this
> and other on my "to look at" list, but I can't really predict when all
> higher priority items would have been dealt with. It's the sad reality
> that in effect this often means RFCs won't be looked at at all. One of
> the many unfortunate effects of our limited review bandwidth.

I fully agree with you on that, and to be honest I think you have already
Been really active in responding and reviewing series. 

Just to clarify the purpose of me sending these reminder emails, from my
perspective, those emails are simply for us to not forget these series (and
also one of the responsibilities of me being a release manager) instead of
pushing authors/maintainers and making them feel stressful - I will try to
rephrase for better wording if my previously emails make people think in
this way.

Kind regards,
Henry

> 
> Jan