This serie aims to add more modularity to some feature that can be excluded
without issues from the build.

The first patch is already reviewed.

Luca Fancellu (5):
  arm/gicv2: make GICv2 driver and vGICv2 optional
  xen/arm: Add asm/domain.h include to kernel.h
  arm/dom0less: put dom0less feature code in a separate module
  xen/arm: Move static memory build code in separate modules
  arm/dom0less: introduce Kconfig for dom0less feature

 xen/arch/arm/Kconfig                      |   28 +
 xen/arch/arm/Makefile                     |    7 +-
 xen/arch/arm/bootfdt.c                    |  161 +-
 xen/arch/arm/dom0less-build.c             | 1086 ++++++
 xen/arch/arm/domain_build.c               | 4096 ++++++---------------
 xen/arch/arm/efi/efi-boot.h               |    4 +
 xen/arch/arm/gic-v3.c                     |    4 +
 xen/arch/arm/include/asm/dom0less-build.h |   35 +
 xen/arch/arm/include/asm/domain_build.h   |   33 +
 xen/arch/arm/include/asm/kernel.h         |    1 +
 xen/arch/arm/include/asm/setup.h          |    1 -
 xen/arch/arm/include/asm/static-memory.h  |   50 +
 xen/arch/arm/include/asm/static-shmem.h   |   72 +
 xen/arch/arm/setup.c                      |   58 +-
 xen/arch/arm/static-memory.c              |  294 ++
 xen/arch/arm/static-shmem.c               |  515 +++
 xen/arch/arm/vgic.c                       |    2 +
 xen/arch/arm/vgic/Makefile                |    4 +-
 18 files changed, 3357 insertions(+), 3094 deletions(-)
 create mode 100644 xen/arch/arm/dom0less-build.c
 create mode 100644 xen/arch/arm/include/asm/dom0less-build.h
 create mode 100644 xen/arch/arm/include/asm/static-memory.h
 create mode 100644 xen/arch/arm/include/asm/static-shmem.h
 create mode 100644 xen/arch/arm/static-memory.c
 create mode 100644 xen/arch/arm/static-shmem.c

-- 
2.34.1

Adding hyperlaunch and x86 maintainers.


Hi Luca,

This patch series is very timely. You might not have realized but we
were just discussing with the hyperlaunch guys to move dom0less code to
common.

Your series is a great step in the right direction. However, we don't
want to move the dom0less code twice because it would make 'git blame'
very hard to use.

I wonder if I could ask you to move the code to xen/common/ instead. I
am not asking you to make it buildable on x86, as that would take more
work and also something along the lines of this patch series from
Christopher:
https://patchew.org/Xen/20230701071835.41599-1-christopher.w.clark@gmail.com/

The new code could be protected by CONFIG_DOM0LESS, and CONFIG_DOM0LESS
could only be selectable on ARM, not on x86.

Would you be OK with doing some extra work to move it to xen/common
instead?

Would the x86 maintainers be OK with it too? Of course further changes
will be needed to make it useable on x86, but looking at the series from
Christopher, the two sets of internal interfaces (dom0less/ARM and
hyperlaunch/x86) are very much aligned and similar already.

Cheers,

Stefano


On Tue, 8 Aug 2023, Luca Fancellu wrote:
> This serie aims to add more modularity to some feature that can be excluded
> without issues from the build.
> 
> The first patch is already reviewed.
> 
> Luca Fancellu (5):
>   arm/gicv2: make GICv2 driver and vGICv2 optional
>   xen/arm: Add asm/domain.h include to kernel.h
>   arm/dom0less: put dom0less feature code in a separate module
>   xen/arm: Move static memory build code in separate modules
>   arm/dom0less: introduce Kconfig for dom0less feature
> 
>  xen/arch/arm/Kconfig                      |   28 +
>  xen/arch/arm/Makefile                     |    7 +-
>  xen/arch/arm/bootfdt.c                    |  161 +-
>  xen/arch/arm/dom0less-build.c             | 1086 ++++++
>  xen/arch/arm/domain_build.c               | 4096 ++++++---------------
>  xen/arch/arm/efi/efi-boot.h               |    4 +
>  xen/arch/arm/gic-v3.c                     |    4 +
>  xen/arch/arm/include/asm/dom0less-build.h |   35 +
>  xen/arch/arm/include/asm/domain_build.h   |   33 +
>  xen/arch/arm/include/asm/kernel.h         |    1 +
>  xen/arch/arm/include/asm/setup.h          |    1 -
>  xen/arch/arm/include/asm/static-memory.h  |   50 +
>  xen/arch/arm/include/asm/static-shmem.h   |   72 +
>  xen/arch/arm/setup.c                      |   58 +-
>  xen/arch/arm/static-memory.c              |  294 ++
>  xen/arch/arm/static-shmem.c               |  515 +++
>  xen/arch/arm/vgic.c                       |    2 +
>  xen/arch/arm/vgic/Makefile                |    4 +-
>  18 files changed, 3357 insertions(+), 3094 deletions(-)
>  create mode 100644 xen/arch/arm/dom0less-build.c
>  create mode 100644 xen/arch/arm/include/asm/dom0less-build.h
>  create mode 100644 xen/arch/arm/include/asm/static-memory.h
>  create mode 100644 xen/arch/arm/include/asm/static-shmem.h
>  create mode 100644 xen/arch/arm/static-memory.c
>  create mode 100644 xen/arch/arm/static-shmem.c
> 
> -- 
> 2.34.1
>

On 09.08.2023 21:51, Stefano Stabellini wrote:
> Would the x86 maintainers be OK with it too? Of course further changes
> will be needed to make it useable on x86, but looking at the series from
> Christopher, the two sets of internal interfaces (dom0less/ARM and
> hyperlaunch/x86) are very much aligned and similar already.

Moving common code to common/ is surely okay with me. How much wants
moving is (apparently) a different question.

Jan

> On 10 Aug 2023, at 10:07, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 09.08.2023 21:51, Stefano Stabellini wrote:
>> Would the x86 maintainers be OK with it too? Of course further changes
>> will be needed to make it useable on x86, but looking at the series from
>> Christopher, the two sets of internal interfaces (dom0less/ARM and
>> hyperlaunch/x86) are very much aligned and similar already.
> 
> Moving common code to common/ is surely okay with me. How much wants
> moving is (apparently) a different question.

Would x86 maintainers (and who is taking care of common/) be ok for the dom0less
code to be part of common/ but in this first stage be protected by a dependency on the
Kconfig ARM?

In a second stage the hyperlaunch people would do the proper modification to use the
common boot modules to delete that dependency.

Provided that we have an answer for the question Michal raised.

Cheers,
Luca

On 10.08.2023 12:43, Luca Fancellu wrote:
>> On 10 Aug 2023, at 10:07, Jan Beulich <jbeulich@suse.com> wrote:
>> On 09.08.2023 21:51, Stefano Stabellini wrote:
>>> Would the x86 maintainers be OK with it too? Of course further changes
>>> will be needed to make it useable on x86, but looking at the series from
>>> Christopher, the two sets of internal interfaces (dom0less/ARM and
>>> hyperlaunch/x86) are very much aligned and similar already.
>>
>> Moving common code to common/ is surely okay with me. How much wants
>> moving is (apparently) a different question.
> 
> Would x86 maintainers (and who is taking care of common/) be ok for the dom0less
> code to be part of common/ but in this first stage be protected by a dependency on the
> Kconfig ARM?

It's actually more than just being okay with this: I wouldn't be okay with
there not being such a guard, as then x86 binaries would carry dead code.

Jan

On 09/08/2023 21:51, Stefano Stabellini wrote:
> 
> 
> Adding hyperlaunch and x86 maintainers.
> 
> 
> Hi Luca,
> 
> This patch series is very timely. You might not have realized but we
> were just discussing with the hyperlaunch guys to move dom0less code to
> common.
> 
> Your series is a great step in the right direction. However, we don't
> want to move the dom0less code twice because it would make 'git blame'
> very hard to use.
> 
> I wonder if I could ask you to move the code to xen/common/ instead. I
> am not asking you to make it buildable on x86, as that would take more
> work and also something along the lines of this patch series from
> Christopher:
> https://patchew.org/Xen/20230701071835.41599-1-christopher.w.clark@gmail.com/
The question is whether we want to move everything related to dom0less parse/build to common.
There are parts that make sense only for Arm. Also, a plain move might not be what
hyperlaunch wants and what Daniel described in his plans for the future. FWIU, hyperlaunch
wants to operate on flattened device tree whereas the majority of dom0less build/parse code
is done using unflattened device tree (FDT is used at the very early stage of the boot and is contained
in bootfdt.c). Maintaining two sets of parsers is not the best idea.

@Daniel,Christopher, what is the reason of using FDT and not DT on hyperlaunch?
Is is because there are parts of configuration that you want to probe early (e.g. XSM module)?

~Michal