1. Patchew
  2. Xen
  3. View series

[XEN][PATCH] common/libfdt: optimize usage

Grygorii Strashko posted 1 patch 2 months, 3 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20251114180130.346755-1-grygorii._5Fstrashko@epam.com
xen/arch/arm/Kconfig       |  4 ++++
xen/common/Kconfig         |  4 ++++
xen/common/libfdt/Kconfig  | 14 ++++++++++++++
xen/common/libfdt/Makefile | 12 +++++++++---
4 files changed, 31 insertions(+), 3 deletions(-)
create mode 100644 xen/common/libfdt/Kconfig
[XEN][PATCH] common/libfdt: optimize usage
Posted by Grygorii Strashko 2 months, 3 weeks ago 
From: Grygorii Strashko <grygorii_strashko@epam.com>

Now all libfdt features are built-it unconditionally, but...

X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
nodes, so full libfdt is not needed in this case and minimal, RO
configuration can be used.

ARM - situation is more complicated:
1) ARM reads Host DT (fdt.c RO)
2) ARM reads passthrough DT (RO)
3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and SW APIs)
4) ARM generates domU DT (there is a mix of WIP and SW APIs)
4) With EFI enabled - ARM needs RW API and fdt_empty_tree
5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API

Hence, add possibility for optimizing libfdt usage by introducing separate
Kconfig options for each libfdt feature and select them where needed.

Following libfdt modules are not used after this change:
 Makefile.libfdt
 fdt_addresses.c
 fdt_strerror.c
 fdt_check.c

Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
---
Not sure about using DOMAIN_BUILD_HELPERS for selecting 
LIBFDT features, as DOMAIN_BUILD_HELPERS doesn't exactly
says that domain's DT will be generated when selected.

 xen/arch/arm/Kconfig       |  4 ++++
 xen/common/Kconfig         |  4 ++++
 xen/common/libfdt/Kconfig  | 14 ++++++++++++++
 xen/common/libfdt/Makefile | 12 +++++++++---
 4 files changed, 31 insertions(+), 3 deletions(-)
 create mode 100644 xen/common/libfdt/Kconfig

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index cf6af68299f6..f10cd3d7effc 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -111,6 +111,8 @@ config ARM_EFI
 	bool "UEFI boot service support"
 	depends on ARM_64 && !MPU
 	default y
+	select LIBFDT_RW
+	select LIBFDT_EMPTY_TREE
 	help
 	  This option provides support for boot services through
 	  UEFI firmware. A UEFI stub is provided to allow Xen to
@@ -149,6 +151,8 @@ config HAS_ITS
 config OVERLAY_DTB
 	bool "DTB overlay support (UNSUPPORTED)" if UNSUPPORTED
 	depends on SYSCTL
+	select LIBFDT_RW
+	select LIBFDT_OVERLAY
 	help
 	  Dynamic addition/removal of Xen device tree nodes using a dtbo.
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 401d5046f6f5..256aff269c3b 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -28,6 +28,8 @@ config DOM0LESS_BOOT
 
 config DOMAIN_BUILD_HELPERS
 	bool
+	select LIBFDT_WIP
+	select LIBFDT_SW
 
 config GRANT_TABLE
 	bool "Grant table support" if EXPERT
@@ -680,4 +682,6 @@ config PM_STATS
 	  Enable collection of performance management statistics to aid in
 	  analyzing and tuning power/performance characteristics of the system
 
+source "common/libfdt/Kconfig"
+
 endmenu
diff --git a/xen/common/libfdt/Kconfig b/xen/common/libfdt/Kconfig
new file mode 100644
index 000000000000..3abd904b2969
--- /dev/null
+++ b/xen/common/libfdt/Kconfig
@@ -0,0 +1,14 @@
+config LIBFDT_WIP
+	bool
+
+config LIBFDT_SW
+    bool
+
+config LIBFDT_RW
+    bool
+
+config LIBFDT_EMPTY_TREE
+    bool
+
+config LIBFDT_OVERLAY
+    bool
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index 6ce679f98f47..c832d1849a5c 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -1,7 +1,13 @@
-include $(src)/Makefile.libfdt
 
 SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
 
+obj-libfdt-y := fdt.o fdt_ro.o
+obj-libfdt-$(CONFIG_LIBFDT_WIP) += fdt_wip.o
+obj-libfdt-$(CONFIG_LIBFDT_SW) += fdt_sw.o
+obj-libfdt-$(CONFIG_LIBFDT_RW) += fdt_rw.o
+obj-libfdt-$(CONFIG_LIBFDT_EMPTY_TREE) += fdt_empty_tree.o
+obj-libfdt-$(CONFIG_LIBFDT_OVERLAY) += fdt_overlay.o
+
 # For CONFIG_OVERLAY_DTB, libfdt functionalities will be needed during runtime.
 ifneq ($(CONFIG_OVERLAY_DTB),y)
 OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s))
@@ -15,7 +21,7 @@ CFLAGS-y += -I$(srctree)/include/xen/libfdt/
 $(obj)/libfdt.o: $(obj)/libfdt-temp.o FORCE
 	$(call if_changed,objcopy)
 
-$(obj)/libfdt-temp.o: $(addprefix $(obj)/,$(LIBFDT_OBJS)) FORCE
+$(obj)/libfdt-temp.o: $(addprefix $(obj)/,$(obj-libfdt-y)) FORCE
 	$(call if_changed,ld)
 
-targets += libfdt-temp.o $(LIBFDT_OBJS)
+targets += libfdt-temp.o $(obj-libfdt-y)
-- 
2.34.1
Re: [XEN][PATCH] common/libfdt: optimize usage
Posted by Andrew Cooper 2 months, 1 week ago 
On 14/11/2025 6:01 pm, Grygorii Strashko wrote:
> From: Grygorii Strashko <grygorii_strashko@epam.com>
>
> Now all libfdt features are built-it unconditionally, but...
>
> X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
> nodes, so full libfdt is not needed in this case and minimal, RO
> configuration can be used.
>
> ARM - situation is more complicated:
> 1) ARM reads Host DT (fdt.c RO)
> 2) ARM reads passthrough DT (RO)
> 3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and SW APIs)
> 4) ARM generates domU DT (there is a mix of WIP and SW APIs)
> 4) With EFI enabled - ARM needs RW API and fdt_empty_tree
> 5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API
>
> Hence, add possibility for optimizing libfdt usage by introducing separate
> Kconfig options for each libfdt feature and select them where needed.
>
> Following libfdt modules are not used after this change:
>  Makefile.libfdt
>  fdt_addresses.c
>  fdt_strerror.c
>  fdt_check.c
>
> Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
> ---
> Not sure about using DOMAIN_BUILD_HELPERS for selecting 
> LIBFDT features, as DOMAIN_BUILD_HELPERS doesn't exactly
> says that domain's DT will be generated when selected.
>
>  xen/arch/arm/Kconfig       |  4 ++++
>  xen/common/Kconfig         |  4 ++++
>  xen/common/libfdt/Kconfig  | 14 ++++++++++++++
>  xen/common/libfdt/Makefile | 12 +++++++++---
>  4 files changed, 31 insertions(+), 3 deletions(-)
>  create mode 100644 xen/common/libfdt/Kconfig
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index cf6af68299f6..f10cd3d7effc 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -111,6 +111,8 @@ config ARM_EFI
>  	bool "UEFI boot service support"
>  	depends on ARM_64 && !MPU
>  	default y
> +	select LIBFDT_RW
> +	select LIBFDT_EMPTY_TREE
>  	help
>  	  This option provides support for boot services through
>  	  UEFI firmware. A UEFI stub is provided to allow Xen to
> @@ -149,6 +151,8 @@ config HAS_ITS
>  config OVERLAY_DTB
>  	bool "DTB overlay support (UNSUPPORTED)" if UNSUPPORTED
>  	depends on SYSCTL
> +	select LIBFDT_RW
> +	select LIBFDT_OVERLAY
>  	help
>  	  Dynamic addition/removal of Xen device tree nodes using a dtbo.
>  
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 401d5046f6f5..256aff269c3b 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -28,6 +28,8 @@ config DOM0LESS_BOOT
>  
>  config DOMAIN_BUILD_HELPERS
>  	bool
> +	select LIBFDT_WIP
> +	select LIBFDT_SW
>  
>  config GRANT_TABLE
>  	bool "Grant table support" if EXPERT
> @@ -680,4 +682,6 @@ config PM_STATS
>  	  Enable collection of performance management statistics to aid in
>  	  analyzing and tuning power/performance characteristics of the system
>  
> +source "common/libfdt/Kconfig"
> +
>  endmenu
> diff --git a/xen/common/libfdt/Kconfig b/xen/common/libfdt/Kconfig
> new file mode 100644
> index 000000000000..3abd904b2969
> --- /dev/null
> +++ b/xen/common/libfdt/Kconfig
> @@ -0,0 +1,14 @@
> +config LIBFDT_WIP
> +	bool
> +
> +config LIBFDT_SW
> +    bool
> +
> +config LIBFDT_RW
> +    bool
> +
> +config LIBFDT_EMPTY_TREE
> +    bool
> +
> +config LIBFDT_OVERLAY
> +    bool
> diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
> index 6ce679f98f47..c832d1849a5c 100644
> --- a/xen/common/libfdt/Makefile
> +++ b/xen/common/libfdt/Makefile
> @@ -1,7 +1,13 @@
> -include $(src)/Makefile.libfdt
>  
>  SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
>  
> +obj-libfdt-y := fdt.o fdt_ro.o
> +obj-libfdt-$(CONFIG_LIBFDT_WIP) += fdt_wip.o
> +obj-libfdt-$(CONFIG_LIBFDT_SW) += fdt_sw.o
> +obj-libfdt-$(CONFIG_LIBFDT_RW) += fdt_rw.o
> +obj-libfdt-$(CONFIG_LIBFDT_EMPTY_TREE) += fdt_empty_tree.o
> +obj-libfdt-$(CONFIG_LIBFDT_OVERLAY) += fdt_overlay.o
> +
>  # For CONFIG_OVERLAY_DTB, libfdt functionalities will be needed during runtime.
>  ifneq ($(CONFIG_OVERLAY_DTB),y)
>  OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s))
> @@ -15,7 +21,7 @@ CFLAGS-y += -I$(srctree)/include/xen/libfdt/
>  $(obj)/libfdt.o: $(obj)/libfdt-temp.o FORCE
>  	$(call if_changed,objcopy)
>  
> -$(obj)/libfdt-temp.o: $(addprefix $(obj)/,$(LIBFDT_OBJS)) FORCE
> +$(obj)/libfdt-temp.o: $(addprefix $(obj)/,$(obj-libfdt-y)) FORCE
>  	$(call if_changed,ld)
>  
> -targets += libfdt-temp.o $(LIBFDT_OBJS)
> +targets += libfdt-temp.o $(obj-libfdt-y)

Pulling together several aspects.

Now that we have xen/lib, library stuff should be in it, including this
libfdt.  I suggest moving it to xen/lib/fdt.

The build system problems are created by using non-standard rules to
bodge the init-ness.  For livepatches, we have `init_or_livepatch` as
friends to do conditional init-ness.  I'd suggest a similar approach here.

You might want a prompt-less CONFIG_LIBFDT_NONINIT which can be selected
by CONFIG_DTB_OVERLAY, because that's going to be better than trying to
make an implication directly about DTB_OVERLAY.


As to other issues hinted at:

* Init coverage.  The only reason we don't have init coverage is because
of the overly-restrictive SPECIAL_DATA_SECTIONS check, and while it
serves a purpose, it does a lot of harm too.  It should be disabled by
things like CONFIG_COVERAGE so that we can retrieve coverage of boot
time paths, and because data placement is not interesting for these
types of builds.

* -f{function,data}-sections and --gc-sections.  This gets dead
code/data elimination with better granularity than the translation unit,
and removes the need for interior ifdefary to achieve the same savings. 
We already have -f*-sections for livepatching, so this is really just
using --gc-sections and will probably net a good win in one fell swoop.

~Andrew
Re: [XEN][PATCH] common/libfdt: optimize usage
Posted by Nicola Vetrini 2 months, 1 week ago 
On 2025-12-03 14:12, Andrew Cooper wrote:
> On 14/11/2025 6:01 pm, Grygorii Strashko wrote:
>> From: Grygorii Strashko <grygorii_strashko@epam.com>
>> 
>> Now all libfdt features are built-it unconditionally, but...
>> 
>> X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
>> nodes, so full libfdt is not needed in this case and minimal, RO
>> configuration can be used.
>> 
>> ARM - situation is more complicated:
>> 1) ARM reads Host DT (fdt.c RO)
>> 2) ARM reads passthrough DT (RO)
>> 3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and 
>> SW APIs)
>> 4) ARM generates domU DT (there is a mix of WIP and SW APIs)
>> 4) With EFI enabled - ARM needs RW API and fdt_empty_tree
>> 5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API
>> 
>> Hence, add possibility for optimizing libfdt usage by introducing 
>> separate
>> Kconfig options for each libfdt feature and select them where needed.
>> 
>> Following libfdt modules are not used after this change:
>>  Makefile.libfdt
>>  fdt_addresses.c
>>  fdt_strerror.c
>>  fdt_check.c
>> 
>> Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
>> ---
>> Not sure about using DOMAIN_BUILD_HELPERS for selecting
>> LIBFDT features, as DOMAIN_BUILD_HELPERS doesn't exactly
>> says that domain's DT will be generated when selected.
>> 
>>  xen/arch/arm/Kconfig       |  4 ++++
>>  xen/common/Kconfig         |  4 ++++
>>  xen/common/libfdt/Kconfig  | 14 ++++++++++++++
>>  xen/common/libfdt/Makefile | 12 +++++++++---
>>  4 files changed, 31 insertions(+), 3 deletions(-)
>>  create mode 100644 xen/common/libfdt/Kconfig
>> 
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index cf6af68299f6..f10cd3d7effc 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -111,6 +111,8 @@ config ARM_EFI
>>  	bool "UEFI boot service support"
>>  	depends on ARM_64 && !MPU
>>  	default y
>> +	select LIBFDT_RW
>> +	select LIBFDT_EMPTY_TREE
>>  	help
>>  	  This option provides support for boot services through
>>  	  UEFI firmware. A UEFI stub is provided to allow Xen to
>> @@ -149,6 +151,8 @@ config HAS_ITS
>>  config OVERLAY_DTB
>>  	bool "DTB overlay support (UNSUPPORTED)" if UNSUPPORTED
>>  	depends on SYSCTL
>> +	select LIBFDT_RW
>> +	select LIBFDT_OVERLAY
>>  	help
>>  	  Dynamic addition/removal of Xen device tree nodes using a dtbo.
>> 
>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>> index 401d5046f6f5..256aff269c3b 100644
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -28,6 +28,8 @@ config DOM0LESS_BOOT
>> 
>>  config DOMAIN_BUILD_HELPERS
>>  	bool
>> +	select LIBFDT_WIP
>> +	select LIBFDT_SW
>> 
>>  config GRANT_TABLE
>>  	bool "Grant table support" if EXPERT
>> @@ -680,4 +682,6 @@ config PM_STATS
>>  	  Enable collection of performance management statistics to aid in
>>  	  analyzing and tuning power/performance characteristics of the 
>> system
>> 
>> +source "common/libfdt/Kconfig"
>> +
>>  endmenu
>> diff --git a/xen/common/libfdt/Kconfig b/xen/common/libfdt/Kconfig
>> new file mode 100644
>> index 000000000000..3abd904b2969
>> --- /dev/null
>> +++ b/xen/common/libfdt/Kconfig
>> @@ -0,0 +1,14 @@
>> +config LIBFDT_WIP
>> +	bool
>> +
>> +config LIBFDT_SW
>> +    bool
>> +
>> +config LIBFDT_RW
>> +    bool
>> +
>> +config LIBFDT_EMPTY_TREE
>> +    bool
>> +
>> +config LIBFDT_OVERLAY
>> +    bool
>> diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
>> index 6ce679f98f47..c832d1849a5c 100644
>> --- a/xen/common/libfdt/Makefile
>> +++ b/xen/common/libfdt/Makefile
>> @@ -1,7 +1,13 @@
>> -include $(src)/Makefile.libfdt
>> 
>>  SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
>> 
>> +obj-libfdt-y := fdt.o fdt_ro.o
>> +obj-libfdt-$(CONFIG_LIBFDT_WIP) += fdt_wip.o
>> +obj-libfdt-$(CONFIG_LIBFDT_SW) += fdt_sw.o
>> +obj-libfdt-$(CONFIG_LIBFDT_RW) += fdt_rw.o
>> +obj-libfdt-$(CONFIG_LIBFDT_EMPTY_TREE) += fdt_empty_tree.o
>> +obj-libfdt-$(CONFIG_LIBFDT_OVERLAY) += fdt_overlay.o
>> +
>>  # For CONFIG_OVERLAY_DTB, libfdt functionalities will be needed 
>> during runtime.
>>  ifneq ($(CONFIG_OVERLAY_DTB),y)
>>  OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section 
>> .$(s)=.init.$(s))
>> @@ -15,7 +21,7 @@ CFLAGS-y += -I$(srctree)/include/xen/libfdt/
>>  $(obj)/libfdt.o: $(obj)/libfdt-temp.o FORCE
>>  	$(call if_changed,objcopy)
>> 
>> -$(obj)/libfdt-temp.o: $(addprefix $(obj)/,$(LIBFDT_OBJS)) FORCE
>> +$(obj)/libfdt-temp.o: $(addprefix $(obj)/,$(obj-libfdt-y)) FORCE
>>  	$(call if_changed,ld)
>> 
>> -targets += libfdt-temp.o $(LIBFDT_OBJS)
>> +targets += libfdt-temp.o $(obj-libfdt-y)
> 
> Pulling together several aspects.
> 
> Now that we have xen/lib, library stuff should be in it, including this
> libfdt.  I suggest moving it to xen/lib/fdt.
> 
> The build system problems are created by using non-standard rules to
> bodge the init-ness.  For livepatches, we have `init_or_livepatch` as
> friends to do conditional init-ness.  I'd suggest a similar approach 
> here.
> 
> You might want a prompt-less CONFIG_LIBFDT_NONINIT which can be 
> selected
> by CONFIG_DTB_OVERLAY, because that's going to be better than trying to
> make an implication directly about DTB_OVERLAY.
> 
> 
> As to other issues hinted at:
> 
> * Init coverage.  The only reason we don't have init coverage is 
> because
> of the overly-restrictive SPECIAL_DATA_SECTIONS check, and while it
> serves a purpose, it does a lot of harm too.  It should be disabled by
> things like CONFIG_COVERAGE so that we can retrieve coverage of boot
> time paths, and because data placement is not interesting for these
> types of builds.
> 
> * -f{function,data}-sections and --gc-sections.  This gets dead
> code/data elimination with better granularity than the translation 
> unit,
> and removes the need for interior ifdefary to achieve the same 
> savings. 
> We already have -f*-sections for livepatching, so this is really just
> using --gc-sections and will probably net a good win in one fell swoop.
> 
> ~Andrew

I didn't check, but moving libfdt code might entail doing some 
replacements in ECLAIR deviations to keep guidelines clean, since there 
are a few assumptions about paths there and in 
"docs/misra/exclude-list.json", which is used also by ECLAIR.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
Re: [XEN][PATCH] common/libfdt: optimize usage
Posted by Grygorii Strashko 2 months, 2 weeks ago 
Hi

On 14.11.25 20:01, Grygorii Strashko wrote:
> From: Grygorii Strashko <grygorii_strashko@epam.com>
> 
> Now all libfdt features are built-it unconditionally, but...
> 
> X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
> nodes, so full libfdt is not needed in this case and minimal, RO
> configuration can be used.
> 
> ARM - situation is more complicated:
> 1) ARM reads Host DT (fdt.c RO)
> 2) ARM reads passthrough DT (RO)
> 3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and SW APIs)
> 4) ARM generates domU DT (there is a mix of WIP and SW APIs)
> 4) With EFI enabled - ARM needs RW API and fdt_empty_tree
> 5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API
> 
> Hence, add possibility for optimizing libfdt usage by introducing separate
> Kconfig options for each libfdt feature and select them where needed.
> 
> Following libfdt modules are not used after this change:
>   Makefile.libfdt
>   fdt_addresses.c
>   fdt_strerror.c
>   fdt_check.c
> 
> Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
> ---
> Not sure about using DOMAIN_BUILD_HELPERS for selecting
> LIBFDT features, as DOMAIN_BUILD_HELPERS doesn't exactly
> says that domain's DT will be generated when selected.
> 
>   xen/arch/arm/Kconfig       |  4 ++++
>   xen/common/Kconfig         |  4 ++++
>   xen/common/libfdt/Kconfig  | 14 ++++++++++++++
>   xen/common/libfdt/Makefile | 12 +++++++++---
>   4 files changed, 31 insertions(+), 3 deletions(-)
>   create mode 100644 xen/common/libfdt/Kconfig
> 

Before continue Kconfig related discussion...

I've been thinking what if we use libfdt as a library (.a)?
We'd get the same result as linker can do optimization basing
on obj granularity while linking with library (.a).

OK. I've started experimenting - obvious choice is to use "lib-y" and
build system will do the rest. But in this case we'll lose ".init" and
libfdt will be built-in.

I've tried to preserve exiting behavior when libfdt is moved in ".init", but,
honestly got lost a bit in Xen build system.

Below diff is what I've came up with - probably no exactly right.

Does it make sense?

diff --git a/xen/Makefile b/xen/Makefile
index a4d53526bd0b..3fb77ab19853 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -464,6 +464,7 @@ ALL_OBJS-y                += arch/$(SRCARCH)/built_in.o
  ALL_OBJS-$(CONFIG_CRYPTO) += crypto/built_in.o
  
  ALL_LIBS-y                := lib/lib.a
+ALL_LIBS-$(CONFIG_LIBFDT) += common/libfdt/libfdt.a
  
  include $(srctree)/arch/$(SRCARCH)/arch.mk
  
  $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y): _c_flags += $(cov-cflags-y)

diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index 6ce679f98f47..e315252c88eb 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -1,21 +1,28 @@
-include $(src)/Makefile.libfdt
  
  SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
  
+obj-libfdt-y := fdt.o fdt_ro.o
+obj-libfdt-y += fdt_wip.o
+obj-libfdt-y += fdt_sw.o
+obj-libfdt-y += fdt_rw.o
+obj-libfdt-y += fdt_empty_tree.o
+obj-libfdt-y += fdt_overlay.o
+
  # For CONFIG_OVERLAY_DTB, libfdt functionalities will be needed during runtime.
  ifneq ($(CONFIG_OVERLAY_DTB),y)
  OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s))
-nocov-y += libfdt.o
+nocov-y += $(obj-libfdt-y)
  endif
  
-obj-y += libfdt.o
-
  CFLAGS-y += -I$(srctree)/include/xen/libfdt/
  
-$(obj)/libfdt.o: $(obj)/libfdt-temp.o FORCE
-       $(call if_changed,objcopy)
+#lib-y += $(obj-libfdt-y)
  
-$(obj)/libfdt-temp.o: $(addprefix $(obj)/,$(LIBFDT_OBJS)) FORCE
-       $(call if_changed,ld)
+$(obj)/libfdt-temp.a: $(addprefix $(obj)/,$(obj-libfdt-y)) FORCE
+       $(call if_changed,ar)
+
+$(obj)/libfdt.a: $(obj)/libfdt-temp.a FORCE
+       $(call if_changed,objcopy)
  
-targets += libfdt-temp.o $(LIBFDT_OBJS)
+extra-y += libfdt.a $(obj-libfdt-y)
+targets += libfdt-temp.a $(obj-libfdt-y)

-- 
Best regards,
-grygorii
Re: [XEN][PATCH] common/libfdt: optimize usage
Posted by Alejandro Vallejo 2 months, 3 weeks ago 
On Fri Nov 14, 2025 at 7:01 PM CET, Grygorii Strashko wrote:
> From: Grygorii Strashko <grygorii_strashko@epam.com>
>
> Now all libfdt features are built-it unconditionally, but...
>
> X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
> nodes, so full libfdt is not needed in this case and minimal, RO
> configuration can be used.
>
> ARM - situation is more complicated:
> 1) ARM reads Host DT (fdt.c RO)
> 2) ARM reads passthrough DT (RO)
> 3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and SW APIs)
> 4) ARM generates domU DT (there is a mix of WIP and SW APIs)
> 4) With EFI enabled - ARM needs RW API and fdt_empty_tree
> 5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API
>
> Hence, add possibility for optimizing libfdt usage by introducing separate
> Kconfig options for each libfdt feature and select them where needed.
>
> Following libfdt modules are not used after this change:
>  Makefile.libfdt
>  fdt_addresses.c
>  fdt_strerror.c
>  fdt_check.c

This is a nice idea, and the less we compile of this nonsense library the
better.

>
> Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
> ---
> Not sure about using DOMAIN_BUILD_HELPERS for selecting 
> LIBFDT features, as DOMAIN_BUILD_HELPERS doesn't exactly
> says that domain's DT will be generated when selected.

We likely want a DEVICE_TREE_WRITER Kconfig, or some such. That would compile
in all code that performs DTB writes and gate the DTB overlay. Not having it
restricts libfdt to fdt.c and fdt_ro.c, and having it adds fdt_rw, and allows
the others depending on EFI and/or overlay settings.

But the helpers themselves are not terribly well organized, so I'd say it's
not strictly required for now.

>
>  xen/arch/arm/Kconfig       |  4 ++++
>  xen/common/Kconfig         |  4 ++++
>  xen/common/libfdt/Kconfig  | 14 ++++++++++++++
>  xen/common/libfdt/Makefile | 12 +++++++++---
>  4 files changed, 31 insertions(+), 3 deletions(-)
>  create mode 100644 xen/common/libfdt/Kconfig
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index cf6af68299f6..f10cd3d7effc 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -111,6 +111,8 @@ config ARM_EFI
>  	bool "UEFI boot service support"
>  	depends on ARM_64 && !MPU
>  	default y
> +	select LIBFDT_RW
> +	select LIBFDT_EMPTY_TREE

Only on UEFI? That's surprising. Why does this entry point need more than
creating a DTB for a domU in dom0less?

>  	help
>  	  This option provides support for boot services through
>  	  UEFI firmware. A UEFI stub is provided to allow Xen to
> @@ -149,6 +151,8 @@ config HAS_ITS
>  config OVERLAY_DTB
>  	bool "DTB overlay support (UNSUPPORTED)" if UNSUPPORTED
>  	depends on SYSCTL
> +	select LIBFDT_RW
> +	select LIBFDT_OVERLAY
>  	help
>  	  Dynamic addition/removal of Xen device tree nodes using a dtbo.
>  
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 401d5046f6f5..256aff269c3b 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -28,6 +28,8 @@ config DOM0LESS_BOOT
>  
>  config DOMAIN_BUILD_HELPERS
>  	bool
> +	select LIBFDT_WIP
> +	select LIBFDT_SW

Out of curiosity, what's the relationship between those libfdt files and the
helpers? What do they use them for?

It's not like LIBFDT_WIP or LIBFDT_SW have very insighful names (through no
fault of your own. The original file organization is dubious at best), so why
not just compile those files conditionally on DOMAIN_BUILD_HELPERS instead?

Something like...

>  
>  config GRANT_TABLE
>  	bool "Grant table support" if EXPERT
> @@ -680,4 +682,6 @@ config PM_STATS
>  	  Enable collection of performance management statistics to aid in
>  	  analyzing and tuning power/performance characteristics of the system
>  
> +source "common/libfdt/Kconfig"
> +
>  endmenu
> diff --git a/xen/common/libfdt/Kconfig b/xen/common/libfdt/Kconfig
> new file mode 100644
> index 000000000000..3abd904b2969
> --- /dev/null
> +++ b/xen/common/libfdt/Kconfig
> @@ -0,0 +1,14 @@
> +config LIBFDT_WIP
> +	bool
> +
> +config LIBFDT_SW
> +    bool
> +
> +config LIBFDT_RW
> +    bool
> +
> +config LIBFDT_EMPTY_TREE
> +    bool
> +
> +config LIBFDT_OVERLAY
> +    bool
> diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
> index 6ce679f98f47..c832d1849a5c 100644
> --- a/xen/common/libfdt/Makefile
> +++ b/xen/common/libfdt/Makefile
> @@ -1,7 +1,13 @@
> -include $(src)/Makefile.libfdt
>  
>  SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
>  
> +obj-libfdt-y := fdt.o fdt_ro.o

> +obj-libfdt-$(CONFIG_LIBFDT_WIP) += fdt_wip.o
> +obj-libfdt-$(CONFIG_LIBFDT_SW) += fdt_sw.o

... turning these two into:

  obj-libfdt-$(CONFIG_DOMAIN_BUILD_HELPERS) += fdt_sw.o fdt_wip.o

Likewise for fdt_empty_tree.o and fdt_overlay.o for ARM_EFI and OVERLAY_DTB
respectively.

> +obj-libfdt-$(CONFIG_LIBFDT_RW) += fdt_rw.o
> +obj-libfdt-$(CONFIG_LIBFDT_EMPTY_TREE) += fdt_empty_tree.o
> +obj-libfdt-$(CONFIG_LIBFDT_OVERLAY) += fdt_overlay.o
> +
>  # For CONFIG_OVERLAY_DTB, libfdt functionalities will be needed during runtime.
>  ifneq ($(CONFIG_OVERLAY_DTB),y)
>  OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s))
> @@ -15,7 +21,7 @@ CFLAGS-y += -I$(srctree)/include/xen/libfdt/
>  $(obj)/libfdt.o: $(obj)/libfdt-temp.o FORCE
>  	$(call if_changed,objcopy)
>  
> -$(obj)/libfdt-temp.o: $(addprefix $(obj)/,$(LIBFDT_OBJS)) FORCE
> +$(obj)/libfdt-temp.o: $(addprefix $(obj)/,$(obj-libfdt-y)) FORCE
>  	$(call if_changed,ld)
>  
> -targets += libfdt-temp.o $(LIBFDT_OBJS)
> +targets += libfdt-temp.o $(obj-libfdt-y)

Cheers,
Alejandro
Re: [XEN][PATCH] common/libfdt: optimize usage
Posted by Jan Beulich 2 months, 3 weeks ago 
On 14.11.2025 19:01, Grygorii Strashko wrote:
> From: Grygorii Strashko <grygorii_strashko@epam.com>
> 
> Now all libfdt features are built-it unconditionally, but...
> 
> X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
> nodes, so full libfdt is not needed in this case and minimal, RO
> configuration can be used.
> 
> ARM - situation is more complicated:
> 1) ARM reads Host DT (fdt.c RO)
> 2) ARM reads passthrough DT (RO)
> 3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and SW APIs)
> 4) ARM generates domU DT (there is a mix of WIP and SW APIs)
> 4) With EFI enabled - ARM needs RW API and fdt_empty_tree
> 5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API

This goes too far, imo.

> --- /dev/null
> +++ b/xen/common/libfdt/Kconfig
> @@ -0,0 +1,14 @@
> +config LIBFDT_WIP
> +	bool
> +
> +config LIBFDT_SW
> +    bool
> +
> +config LIBFDT_RW
> +    bool
> +
> +config LIBFDT_EMPTY_TREE
> +    bool
> +
> +config LIBFDT_OVERLAY
> +    bool

Nit: Inconsistent indentation.

Also, how would one be to guess which of these may need selecting? What do
"WIP", "SW", and "RW" stand for? What exactly would "empty tree" mean? Yes,
you follow what the files are named under libfdt/, but that naming is
overly cryptic, too. The comments at the top of these files also don't
say anything helpful.

Jan
Re: [XEN][PATCH] common/libfdt: optimize usage
Posted by Grygorii Strashko 2 months, 3 weeks ago 

On 17.11.25 11:31, Jan Beulich wrote:
> On 14.11.2025 19:01, Grygorii Strashko wrote:
>> From: Grygorii Strashko <grygorii_strashko@epam.com>
>>
>> Now all libfdt features are built-it unconditionally, but...
>>
>> X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
>> nodes, so full libfdt is not needed in this case and minimal, RO
>> configuration can be used.
>>
>> ARM - situation is more complicated:
>> 1) ARM reads Host DT (fdt.c RO)
>> 2) ARM reads passthrough DT (RO)
>> 3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and SW APIs)
>> 4) ARM generates domU DT (there is a mix of WIP and SW APIs)
>> 4) With EFI enabled - ARM needs RW API and fdt_empty_tree
>> 5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API
> 
> This goes too far, imo.
> 
>> --- /dev/null
>> +++ b/xen/common/libfdt/Kconfig
>> @@ -0,0 +1,14 @@
>> +config LIBFDT_WIP

"Write-in-place"
- update property in place
- NOP the property or node
(no resize)

>> +	bool
>> +
>> +config LIBFDT_SW

"Sequential-write"
Used to create DT in a buffer sequentially in one pass
fdt_create
  fdt_begin_node
   fdt_property
   ...
  fdt_end_node
...
fdt_finish

>> +    bool
>> +
>> +config LIBFDT_RW

"Full read-write"
- add/del/change nodes or properties in fdt blob
- no automatic resize

>> +    bool
>> +
>> +config LIBFDT_EMPTY_TREE

Enables fdt_create_empty_tree() helper

>> +    bool
>> +
>> +config LIBFDT_OVERLAY

Enables DT overlay helpers (deps: RW, WIP)

>> +    bool
> 
> Nit: Inconsistent indentation.
> 
> Also, how would one be to guess which of these may need selecting? What do
> "WIP", "SW", and "RW" stand for? What exactly would "empty tree" mean? Yes,
> you follow what the files are named under libfdt/, but that naming is
> overly cryptic, too. The comments at the top of these files also don't
> say anything helpful.

Indeed.

-- 
Best regards,
-grygorii
Re: [XEN][PATCH] common/libfdt: optimize usage
Posted by Jan Beulich 2 months, 3 weeks ago 
On 17.11.2025 10:31, Jan Beulich wrote:
> On 14.11.2025 19:01, Grygorii Strashko wrote:
>> From: Grygorii Strashko <grygorii_strashko@epam.com>
>>
>> Now all libfdt features are built-it unconditionally, but...
>>
>> X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
>> nodes, so full libfdt is not needed in this case and minimal, RO
>> configuration can be used.
>>
>> ARM - situation is more complicated:
>> 1) ARM reads Host DT (fdt.c RO)
>> 2) ARM reads passthrough DT (RO)
>> 3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and SW APIs)
>> 4) ARM generates domU DT (there is a mix of WIP and SW APIs)
>> 4) With EFI enabled - ARM needs RW API and fdt_empty_tree
>> 5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API
> 
> This goes too far, imo.

The more that, unless OVERLAY_DTB=y, all code and data moves to .init.*. Is
coverage in in .init.* really of as much concern as runtime code/data?

Jan
Re: [XEN][PATCH] common/libfdt: optimize usage
Posted by Grygorii Strashko 2 months, 2 weeks ago 

On 17.11.25 11:34, Jan Beulich wrote:
> On 17.11.2025 10:31, Jan Beulich wrote:
>> On 14.11.2025 19:01, Grygorii Strashko wrote:
>>> From: Grygorii Strashko <grygorii_strashko@epam.com>
>>>
>>> Now all libfdt features are built-it unconditionally, but...
>>>
>>> X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
>>> nodes, so full libfdt is not needed in this case and minimal, RO
>>> configuration can be used.
>>>
>>> ARM - situation is more complicated:
>>> 1) ARM reads Host DT (fdt.c RO)
>>> 2) ARM reads passthrough DT (RO)
>>> 3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and SW APIs)
>>> 4) ARM generates domU DT (there is a mix of WIP and SW APIs)
>>> 4) With EFI enabled - ARM needs RW API and fdt_empty_tree
>>> 5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API
>>
>> This goes too far, imo.
> 
> The more that, unless OVERLAY_DTB=y, all code and data moves to .init.*. Is
> coverage in in .init.* really of as much concern as runtime code/data?

It is less priority, but still is. Any way it is unnecessary build units (build time) and
increased binary size.


Actually, I see interesting behavior - when build with CONFIG_CC_SPLIT_SECTIONS=y (CONFIG_LIVEPATCH=y)
the libfdt code is not moved in ".init"

0xa000027aa10 T fdt_ro_probe_

0xa00002c0000 T __init_begin
  

-- 
Best regards,
-grygorii
Re: [XEN][PATCH] common/libfdt: optimize usage
Posted by Jan Beulich 2 months, 2 weeks ago 
On 21.11.2025 11:59, Grygorii Strashko wrote:
> 
> 
> On 17.11.25 11:34, Jan Beulich wrote:
>> On 17.11.2025 10:31, Jan Beulich wrote:
>>> On 14.11.2025 19:01, Grygorii Strashko wrote:
>>>> From: Grygorii Strashko <grygorii_strashko@epam.com>
>>>>
>>>> Now all libfdt features are built-it unconditionally, but...
>>>>
>>>> X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
>>>> nodes, so full libfdt is not needed in this case and minimal, RO
>>>> configuration can be used.
>>>>
>>>> ARM - situation is more complicated:
>>>> 1) ARM reads Host DT (fdt.c RO)
>>>> 2) ARM reads passthrough DT (RO)
>>>> 3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and SW APIs)
>>>> 4) ARM generates domU DT (there is a mix of WIP and SW APIs)
>>>> 4) With EFI enabled - ARM needs RW API and fdt_empty_tree
>>>> 5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API
>>>
>>> This goes too far, imo.
>>
>> The more that, unless OVERLAY_DTB=y, all code and data moves to .init.*. Is
>> coverage in in .init.* really of as much concern as runtime code/data?
> 
> It is less priority, but still is. Any way it is unnecessary build units (build time) and
> increased binary size.
> 
> 
> Actually, I see interesting behavior - when build with CONFIG_CC_SPLIT_SECTIONS=y (CONFIG_LIVEPATCH=y)
> the libfdt code is not moved in ".init"
> 
> 0xa000027aa10 T fdt_ro_probe_
> 
> 0xa00002c0000 T __init_begin

Hmm, that's a bug, resulting from libfdt/ not using the usual machinery to do the
conversion.

Jan

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.