All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	scott.davis@starlab.io, christopher.clark@starlab.io,
	sstabellini@kernel.org
Subject: [RFC PATCH 0/4] Introducing a common representation of boot info
Date: Mon, 30 May 2022 22:41:22 -0400	[thread overview]
Message-ID: <20220531024127.23669-1-dpsmith@apertussolutions.com> (raw)

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



             reply	other threads:[~2022-05-30 22:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-31  2:41 Daniel P. Smith [this message]
2022-05-31  2:41 ` [RFC PATCH 1/4] kconfig: allow configuration of maximum modules Daniel P. Smith
2022-05-31  9:07   ` Bertrand Marquis
2022-05-31 10:45     ` Daniel P. Smith
2022-05-31 10:49       ` Bertrand Marquis
2022-05-31 10:56         ` Daniel P. Smith
2022-05-31 13:52       ` Roger Pau Monné
2022-05-31 13:54         ` Jan Beulich
2022-06-01  7:40         ` George Dunlap
2022-06-01  9:06           ` Roger Pau Monné
2022-06-07 11:34             ` Julien Grall
2022-05-31  9:25   ` Julien Grall
2022-05-31 10:53     ` Daniel P. Smith
2022-06-01 17:35       ` Julien Grall
2022-06-02  8:49         ` Jan Beulich
2022-06-07 11:37           ` Julien Grall
2022-06-03 12:58   ` Jan Beulich
2022-05-31  2:41 ` [RFC PATCH 2/4] headers: introduce generalized boot info Daniel P. Smith
2022-05-31  2:41 ` [RFC PATCH 3/4] x86: adopt new boot info structures Daniel P. Smith
2022-05-31  2:41 ` [RFC PATCH 4/4] x86: refactor entrypoints to new boot info Daniel P. Smith
2022-07-06  7:30 ` [RFC PATCH 0/4] Introducing a common representation of " Henry Wang
2022-07-06  9:01   ` Jan Beulich
2022-07-06  9:28     ` Henry Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220531024127.23669-1-dpsmith@apertussolutions.com \
    --to=dpsmith@apertussolutions.com \
    --cc=christopher.clark@starlab.io \
    --cc=scott.davis@starlab.io \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.