* Re: [XEN][PATCH] common/libfdt: optimize usage
2025-11-14 18:01 [XEN][PATCH] common/libfdt: optimize usage Grygorii Strashko
@ 2025-11-17 9:31 ` Jan Beulich
2025-11-17 9:34 ` Jan Beulich
2025-11-18 19:43 ` Grygorii Strashko
2025-11-17 14:34 ` Alejandro Vallejo
` (2 subsequent siblings)
3 siblings, 2 replies; 10+ messages in thread
From: Jan Beulich @ 2025-11-17 9:31 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis, Michal Orzel,
Volodymyr Babchuk, Andrew Cooper, Anthony PERARD,
Roger Pau Monné, Alejandro Vallejo, Jason Andryuk,
xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [XEN][PATCH] common/libfdt: optimize usage
2025-11-17 9:31 ` Jan Beulich
@ 2025-11-17 9:34 ` Jan Beulich
2025-11-21 10:59 ` Grygorii Strashko
2025-11-18 19:43 ` Grygorii Strashko
1 sibling, 1 reply; 10+ messages in thread
From: Jan Beulich @ 2025-11-17 9:34 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis, Michal Orzel,
Volodymyr Babchuk, Andrew Cooper, Anthony PERARD,
Roger Pau Monné, Alejandro Vallejo, Jason Andryuk,
xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [XEN][PATCH] common/libfdt: optimize usage
2025-11-17 9:34 ` Jan Beulich
@ 2025-11-21 10:59 ` Grygorii Strashko
2025-11-21 11:28 ` Jan Beulich
0 siblings, 1 reply; 10+ messages in thread
From: Grygorii Strashko @ 2025-11-21 10:59 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis, Michal Orzel,
Volodymyr Babchuk, Andrew Cooper, Anthony PERARD,
Roger Pau Monné, Alejandro Vallejo, Jason Andryuk,
xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [XEN][PATCH] common/libfdt: optimize usage
2025-11-21 10:59 ` Grygorii Strashko
@ 2025-11-21 11:28 ` Jan Beulich
0 siblings, 0 replies; 10+ messages in thread
From: Jan Beulich @ 2025-11-21 11:28 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis, Michal Orzel,
Volodymyr Babchuk, Andrew Cooper, Anthony PERARD,
Roger Pau Monné, Alejandro Vallejo, Jason Andryuk,
xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [XEN][PATCH] common/libfdt: optimize usage
2025-11-17 9:31 ` Jan Beulich
2025-11-17 9:34 ` Jan Beulich
@ 2025-11-18 19:43 ` Grygorii Strashko
1 sibling, 0 replies; 10+ messages in thread
From: Grygorii Strashko @ 2025-11-18 19:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis, Michal Orzel,
Volodymyr Babchuk, Andrew Cooper, Anthony PERARD,
Roger Pau Monné, Alejandro Vallejo, Jason Andryuk,
xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [XEN][PATCH] common/libfdt: optimize usage
2025-11-14 18:01 [XEN][PATCH] common/libfdt: optimize usage Grygorii Strashko
2025-11-17 9:31 ` Jan Beulich
@ 2025-11-17 14:34 ` Alejandro Vallejo
2025-11-21 11:01 ` Grygorii Strashko
2025-12-03 13:12 ` Andrew Cooper
3 siblings, 0 replies; 10+ messages in thread
From: Alejandro Vallejo @ 2025-11-17 14:34 UTC (permalink / raw)
To: Grygorii Strashko, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis, Michal Orzel,
Volodymyr Babchuk, Andrew Cooper, Anthony PERARD, Jan Beulich,
Roger Pau Monné, Jason Andryuk
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [XEN][PATCH] common/libfdt: optimize usage
2025-11-14 18:01 [XEN][PATCH] common/libfdt: optimize usage Grygorii Strashko
2025-11-17 9:31 ` Jan Beulich
2025-11-17 14:34 ` Alejandro Vallejo
@ 2025-11-21 11:01 ` Grygorii Strashko
2025-12-03 13:12 ` Andrew Cooper
3 siblings, 0 replies; 10+ messages in thread
From: Grygorii Strashko @ 2025-11-21 11:01 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis, Michal Orzel,
Volodymyr Babchuk, Andrew Cooper, Anthony PERARD, Jan Beulich,
Roger Pau Monné, Alejandro Vallejo, Jason Andryuk
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
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [XEN][PATCH] common/libfdt: optimize usage
2025-11-14 18:01 [XEN][PATCH] common/libfdt: optimize usage Grygorii Strashko
` (2 preceding siblings ...)
2025-11-21 11:01 ` Grygorii Strashko
@ 2025-12-03 13:12 ` Andrew Cooper
2025-12-03 14:12 ` Nicola Vetrini
3 siblings, 1 reply; 10+ messages in thread
From: Andrew Cooper @ 2025-12-03 13:12 UTC (permalink / raw)
To: Grygorii Strashko, xen-devel@lists.xenproject.org
Cc: andrew.cooper3, Stefano Stabellini, Julien Grall,
Bertrand Marquis, Michal Orzel, Volodymyr Babchuk, Anthony PERARD,
Jan Beulich, Roger Pau Monné, Alejandro Vallejo,
Jason Andryuk
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [XEN][PATCH] common/libfdt: optimize usage
2025-12-03 13:12 ` Andrew Cooper
@ 2025-12-03 14:12 ` Nicola Vetrini
0 siblings, 0 replies; 10+ messages in thread
From: Nicola Vetrini @ 2025-12-03 14:12 UTC (permalink / raw)
To: Andrew Cooper
Cc: Grygorii Strashko, xen-devel, Stefano Stabellini, Julien Grall,
Bertrand Marquis, Michal Orzel, Volodymyr Babchuk, Anthony PERARD,
Jan Beulich, Roger Pau Monné, Alejandro Vallejo,
Jason Andryuk
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
^ permalink raw reply [flat|nested] 10+ messages in thread