mbox series

[v3,00/16] Hyperlaunch device tree for dom0

Message ID 20250408160802.49870-1-agarciav@amd.com (mailing list archive)
Headers show
Series Hyperlaunch device tree for dom0 | expand

Message

Alejandro Vallejo April 8, 2025, 4:07 p.m. UTC 
Hi,

This is an updated version of the hyperlaunch DTB series, with pending
feedback addressed. Some parts (notably the way modules are located) has
changed a little and is more generic with less duplication.

I've purposefully not added my S-by on anything I haven't touched
(besides rebasing) as most of the feedback had already been addressed by
Jason by the time I looked at it and it would be utterly nonsensical to
give myself authorship over it.

I'll be looking after the series moving forward.

v3 pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/1758167851

v2: https://lore.kernel.org/xen-devel/20241226165740.29812-1-dpsmith@apertussolutions.com/
v1: https://lore.kernel.org/xen-devel/20241123182044.30687-1-dpsmith@apertussolutions.com/

Cheers,
Alejandro

========= Original cover letter:

The Hyperlaunch device tree for dom0 series is the second split out for the
introduction of the Hyperlaunch domain builder logic. These changes focus on
introducing the ability to express a domain configuration that is then used to
populate the struct boot_domain structure for dom0. This ability to express a
domain configuration provides the next step towards a general domain builder.

The splitting of Hyperlaunch into a set of series are twofold, to reduce the
effort in reviewing a much larger series, and to reduce the effort in handling
the knock-on effects to the construction logic from requested review changes.

=========

Alejandro Vallejo (1):
  x86/hyperlaunch: Add helpers to locate multiboot modules

Daniel P. Smith (15):
  x86/boot: introduce boot domain
  x86/boot: introduce domid field to struct boot_domain
  x86/boot: add cmdline to struct boot_domain
  kconfig: introduce option to independently enable libfdt
  kconfig: introduce domain builder config option
  x86/hyperlaunch: introduce the domain builder
  x86/hyperlaunch: initial support for hyperlaunch device tree
  x86/hyperlaunch: locate dom0 kernel with hyperlaunch
  x86/hyperlaunch: obtain cmdline from device tree
  x86/hyperlaunch: locate dom0 initrd with hyperlaunch
  x86/hyperlaunch: add domain id parsing to domain config
  x86/hyperlaunch: specify dom0 mode with device tree
  x86/hyperlaunch: add memory parsing to domain config
  x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree
  x86/hyperlaunch: add capabilities to boot domain

 xen/arch/x86/Kconfig                      |   2 +
 xen/arch/x86/Makefile                     |   1 +
 xen/arch/x86/dom0_build.c                 |  19 +-
 xen/arch/x86/domain-builder/Kconfig       |  15 +
 xen/arch/x86/domain-builder/Makefile      |   2 +
 xen/arch/x86/domain-builder/core.c        | 112 ++++++
 xen/arch/x86/domain-builder/fdt.c         | 448 ++++++++++++++++++++++
 xen/arch/x86/domain-builder/fdt.h         |  53 +++
 xen/arch/x86/hvm/dom0_build.c             |  35 +-
 xen/arch/x86/include/asm/boot-domain.h    |  48 +++
 xen/arch/x86/include/asm/bootinfo.h       |  15 +-
 xen/arch/x86/include/asm/dom0_build.h     |   6 +-
 xen/arch/x86/include/asm/domain-builder.h |  12 +
 xen/arch/x86/include/asm/setup.h          |   4 +-
 xen/arch/x86/pv/dom0_build.c              |  28 +-
 xen/arch/x86/setup.c                      | 106 +++--
 xen/common/Kconfig                        |   4 +
 xen/common/Makefile                       |   2 +-
 xen/include/xen/libfdt/libfdt-xen.h       | 101 +++++
 19 files changed, 927 insertions(+), 86 deletions(-)
 create mode 100644 xen/arch/x86/domain-builder/Kconfig
 create mode 100644 xen/arch/x86/domain-builder/Makefile
 create mode 100644 xen/arch/x86/domain-builder/core.c
 create mode 100644 xen/arch/x86/domain-builder/fdt.c
 create mode 100644 xen/arch/x86/domain-builder/fdt.h
 create mode 100644 xen/arch/x86/include/asm/boot-domain.h
 create mode 100644 xen/arch/x86/include/asm/domain-builder.h

Comments

Jan Beulich April 9, 2025, 6:29 a.m. UTC | #1 
On 08.04.2025 18:07, Alejandro Vallejo wrote:
> I've purposefully not added my S-by on anything I haven't touched
> (besides rebasing) as most of the feedback had already been addressed by
> Jason by the time I looked at it and it would be utterly nonsensical to
> give myself authorship over it.

My understanding of it is that S-o-b doesn't indicate (only) authorship.
See docs/process/sending-patches.pandoc "Developer's Certificate of Origin
1.1" point (c). And what you would want to demonstrate with adding your
own one is agreement with (d) there. With this I'm not even sure I could
commit patches becoming ready in their present form.

Jan
Alejandro Vallejo April 9, 2025, 10:19 a.m. UTC | #2 
On Wed Apr 9, 2025 at 7:29 AM BST, Jan Beulich wrote:
> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>> I've purposefully not added my S-by on anything I haven't touched
>> (besides rebasing) as most of the feedback had already been addressed by
>> Jason by the time I looked at it and it would be utterly nonsensical to
>> give myself authorship over it.
>
> My understanding of it is that S-o-b doesn't indicate (only) authorship.
> See docs/process/sending-patches.pandoc "Developer's Certificate of Origin
> 1.1" point (c). And what you would want to demonstrate with adding your
> own one is agreement with (d) there. With this I'm not even sure I could
> commit patches becoming ready in their present form.
>
> Jan

Fair enough. Will add myself everywhere on v4, then. Seeing as there's
still changes to go through.

Cheers,
Alejandro
Alejandro Vallejo April 9, 2025, 10:39 a.m. UTC | #3 
On Wed Apr 9, 2025 at 11:19 AM BST, Alejandro Vallejo wrote:
> On Wed Apr 9, 2025 at 7:29 AM BST, Jan Beulich wrote:
>> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>>> I've purposefully not added my S-by on anything I haven't touched
>>> (besides rebasing) as most of the feedback had already been addressed by
>>> Jason by the time I looked at it and it would be utterly nonsensical to
>>> give myself authorship over it.
>>
>> My understanding of it is that S-o-b doesn't indicate (only) authorship.
>> See docs/process/sending-patches.pandoc "Developer's Certificate of Origin
>> 1.1" point (c). And what you would want to demonstrate with adding your
>> own one is agreement with (d) there. With this I'm not even sure I could
>> commit patches becoming ready in their present form.
>>
>> Jan
>
> Fair enough. Will add myself everywhere on v4, then. Seeing as there's
> still changes to go through.
>
> Cheers,
> Alejandro

And FTAOD, that also meant an implicit

    Signed-off-by: Alejandro Vallejo <agarciav@amd.com>

to everything in v3.

Cheers,
Alejandro