[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN][PATCH] common/libfdt: optimize usage
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
- Date: Fri, 21 Nov 2025 12:59:38 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z4tC2GMrtJkMNkvOMYxL61qeZ8+Dt2rgTa8JqEiYuDo=; b=o99xzyp4Jtk9tt/HO6PVsGA5QlC9GMbbJpRLEvdhqxY1+Mmh5iNvYQuCmnKSs7ES8oqff5fE9E0rnZXroVP4GaUFzd9nz3Gj22d+guwgyhdSgVjn2qRx2oVwfubE1Gh2Ep3Obt+sSEjYdXBF6+R7bBbylSG9DrDfllX/Wzk9bagonDWkyI/MHJzEvgkx3VT8HHtXYnJrEh1ZCOe3h8ZEv+8rSkHx6bfe7MJ2gq1BdRIIk1SsbgG/mhPnJJyqe3KTeNGABlkT0NIxsZUBWY5nklQaT7fdqbbPQqhob9be8uvzOcKbw2iUG0tGk0hUghiDcht9z0vTDEQummbx0iAtsw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ekG4XZGGWmL+SzsevWPGCrXkCmKvPeBYZ6ag9H0O29BXh1oeswnPRsmjIgWNtSjua68U6UE38BQuglL9jIOhpYh8Q78fH9M6zoaaXqQVg3GrIIt7gbdyMVqMLbjcB2AY4Siwd+yf3erIBRMDxomwht6HI7ghzRBuQGkmg5TxVG6ISAo8DyUDbgWEaq6vYF7tZEXl6e+pBSlJuz0SJ+NLfPeKHnLBlc3g8l9sO6D63FF25F24XLjDwTpZgBsTc/oJvOejq7/FWOR5PoXuUdym36v7ZDrXj8w6KPWGL5whQ+ripaLUSlEZUIjM42ylTpuwGL3VM1VBaqNWwfyq5SqRCA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>, Jason Andryuk <jason.andryuk@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 21 Nov 2025 11:01:42 +0000
- List-id: Xen developer discussion <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@xxxxxxxx>
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
|
