On 01.07.2023 09:18, Christopher Clark wrote:
> This is a v3 series of work for Hyperlaunch for the Xen hypervisor,
> an update to v2 and implementing a subset of the v1 series and functionality,
> with changes made to address the community feedback provided on the patches.
> Changes since the earlier versions of the series are described below.
>
> The patches in this series are primarily derived from patches 2-4 of the
> v1 full series, in a series of smaller patches for ease of review.
>
> Thanks to AMD for supporting this work.
>
> Documentation on Hyperlaunch:
> https://wiki.xenproject.org/wiki/Hyperlaunch
>
> v1 Hyperlaunch patch series:
> https://lists.xenproject.org/archives/html/xen-devel/2022-07/msg00345.html
>
> thanks
>
> Christopher
>
> Changes since v2:
> - combined v2 patches 7 and 8 for common review
> - rebased the v2 series onto the current tip of staging (sorry)
> - fixed the placement of the patch changelogs
> - provided the changes description in the cover letter
>
> Changes since v1:
> - the v2 and v3 series implement functionality from v1 patches 2-4
> - v2 series objective is to enable efficient patch review in support
> of merging the functionality into the hypervisor. It implements a
> subset of the v1 series, incorporating changes from community
> feedback.
> - the bootstrap map is made accessible early in the v2 series via both
> multiboot and boot module arguments until later in the series where
> multiboot use is retired. This allows for incremental conversion across
> several patches from multiboot to boot modules.
> - the 32-bit x86 boot environment header is removed, and changes are
> made to allow the new common bootinfo headers to be used instead.
> - Arm and RISC-V architecture bootinfo headers are added to ensure that
> builds on those architectures can complete correctly.
> - The KConfig patch to set the maximum number of boot modules allowed
> is not included in this series, replaced with a static maximum define.
>
> Christopher Clark (10):
> x86 setup: move x86 boot module counting into a new boot_info struct
> x86 setup: per-arch bootmodule structure, headroom field
> x86 setup: change bootstrap map to accept new boot module structures
> x86 setup: porting dom0 construction logic to boot module structures
> xsm: switch XSM init to boot info structures
> x86 setup, microcode: switch to the new bootinfo structures
While up to here things are an integral part of your hyperlaunch work, ...
> x86 boot: define paddr_t and add macros for typedefing struct pointers
> x86, arm, riscv: add per-arch bootinfo headers
> arm setup: use common integer-typed bootmod definition
> x86 setup: refactor efi, pvh and multiboot entrypoints to new boot
> info
... I'm getting the impression that the rest is unrelated tidying. I
wonder if we really want to take that churn right now; besides this
needlessly bloating the series and pulling away attention from the
functionally important parts, I could also see there being a need for
changes later in the course of your hyperlaunch work, which might then
have a knock-on effect on what's being carried through here to very
early boot code. Early boot code, tending to be fragile, would perhaps
best not be altered more than necessary. I wonder what the other x86
maintainers think ...
Jan