| Message ID | 20230808080010.3858575-1-luca.fancellu@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fine granular configuration | expand |
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: > > > 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
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