From: Pierrick Bouvier <pierrick.bouvier@linaro.org>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
qemu-devel@nongnu.org
Cc: Anton Johansson <anjo@rev.ng>
Subject: Re: [RFC PATCH v4 06/19] hw/arm: Filter machine types for qemu-system-arm/aarch64 binaries
Date: Wed, 23 Apr 2025 13:10:43 -0700 [thread overview]
Message-ID: <b181a62c-c9cf-4d33-b694-b5099069ee79@linaro.org> (raw)
In-Reply-To: <ee9d6b5e-0a38-4237-aa4e-2aebbe9785d8@linaro.org>
On 4/23/25 12:53, Philippe Mathieu-Daudé wrote:
> On 23/4/25 21:33, Pierrick Bouvier wrote:
>> On 4/23/25 12:12, Richard Henderson wrote:
>>>> @Richard:
>>>> Is it a concern regarding code maintenance, or potential impact
>>>> on .data?
>>>
>>> I was thinking of impact on .data, especially with so many.
>>>
>>
>> du qemu-system-aarch64 optimized and stripped (in kB):
>> 31880 upstream
>> 31896 upstream + this series
>
> FYI same tag as a branch with InterfaceInfo constified:
> https://gitlab.com/philmd/qemu/-/tree/single-binary-hw-arm-rfc-v4-const
>
Maybe I missed something, but machine interfaces are not const on this
branch.
>> So we have +16kB which is a size increase of +0.0005%.
>> Even if we project something similar on other architectures (let's say
>> x10), the final impact on binary size should be < 0.005%.
>>
>> Maybe it's a reasonable impact considering the trade off on coherency
>> and readability through the codebase?
>> Else, in case we make this array const, can we expect the linker to
>> deduplicate it? I'm not familiar with how final .data section is assembled.
>
next prev parent reply other threads:[~2025-04-23 20:11 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 14:54 [RFC PATCH v4 00/19] single-binary: Make hw/arm/ common Philippe Mathieu-Daudé
2025-04-22 14:54 ` [RFC PATCH v4 01/19] qapi: Rename TargetInfo structure as QemuTargetInfo Philippe Mathieu-Daudé
2025-04-22 14:57 ` Philippe Mathieu-Daudé
2025-04-22 17:33 ` Markus Armbruster
2025-04-22 14:54 ` [RFC PATCH v4 02/19] qemu: Convert target_name() to TargetInfo API Philippe Mathieu-Daudé
2025-04-22 17:27 ` Richard Henderson
2025-04-22 17:28 ` Richard Henderson
2025-04-22 14:54 ` [RFC PATCH v4 03/19] system/vl: Filter machine list available for a particular target binary Philippe Mathieu-Daudé
2025-04-22 17:29 ` Richard Henderson
2025-04-22 14:54 ` [RFC PATCH v4 04/19] hw/arm: Register TYPE_TARGET_ARM/AARCH64_MACHINE QOM interfaces Philippe Mathieu-Daudé
2025-04-22 17:31 ` Richard Henderson
2025-04-22 14:54 ` [RFC PATCH v4 05/19] hw/core: Allow ARM/Aarch64 binaries to use the 'none' machine Philippe Mathieu-Daudé
2025-04-22 17:34 ` Richard Henderson
2025-04-22 14:54 ` [RFC PATCH v4 06/19] hw/arm: Filter machine types for qemu-system-arm/aarch64 binaries Philippe Mathieu-Daudé
2025-04-22 17:40 ` Richard Henderson
2025-04-23 16:34 ` Philippe Mathieu-Daudé
2025-04-23 17:43 ` Pierrick Bouvier
2025-04-23 19:12 ` Richard Henderson
2025-04-23 19:33 ` Pierrick Bouvier
2025-04-23 19:53 ` Philippe Mathieu-Daudé
2025-04-23 20:10 ` Pierrick Bouvier [this message]
2025-04-23 20:04 ` Richard Henderson
2025-04-23 20:12 ` Pierrick Bouvier
2025-04-23 17:07 ` Philippe Mathieu-Daudé
2025-04-22 14:54 ` [RFC PATCH v4 07/19] meson: Prepare to accept per-binary TargetInfo structure implementation Philippe Mathieu-Daudé
2025-04-22 17:41 ` Richard Henderson
2025-04-22 14:54 ` [RFC PATCH v4 08/19] config/target: Implement per-binary TargetInfo structure (ARM, AARCH64) Philippe Mathieu-Daudé
2025-04-22 17:42 ` Richard Henderson
2025-04-22 14:54 ` [RFC PATCH v4 09/19] hw/arm/aspeed: Build objects once Philippe Mathieu-Daudé
2025-04-22 17:42 ` Richard Henderson
2025-04-22 14:54 ` [RFC PATCH v4 10/19] hw/arm/raspi: " Philippe Mathieu-Daudé
2025-04-22 17:43 ` Richard Henderson
2025-04-22 14:54 ` [RFC PATCH v4 11/19] hw/core/machine: Allow dynamic registration of valid CPU types Philippe Mathieu-Daudé
2025-04-22 17:54 ` Richard Henderson
2025-04-22 18:06 ` Pierrick Bouvier
2025-04-22 14:54 ` [RFC PATCH v4 12/19] hw/arm/virt: Register valid CPU types dynamically Philippe Mathieu-Daudé
2025-04-22 17:56 ` Richard Henderson
2025-04-22 18:10 ` Pierrick Bouvier
2025-04-22 18:18 ` Philippe Mathieu-Daudé
2025-04-22 14:54 ` [RFC PATCH v4 13/19] hw/arm/virt: Check accelerator availability at runtime Philippe Mathieu-Daudé
2025-04-22 17:56 ` Richard Henderson
2025-04-22 18:18 ` Pierrick Bouvier
2025-04-22 14:54 ` [RFC PATCH v4 14/19] qemu/target_info: Add %target_arch field to TargetInfo Philippe Mathieu-Daudé
2025-04-22 17:46 ` Richard Henderson
2025-04-22 18:20 ` Pierrick Bouvier
2025-04-22 18:24 ` Philippe Mathieu-Daudé
2025-04-22 18:30 ` Pierrick Bouvier
2025-04-23 5:34 ` Philippe Mathieu-Daudé
2025-04-23 6:24 ` Pierrick Bouvier
2025-04-23 6:28 ` Pierrick Bouvier
2025-04-23 9:14 ` Philippe Mathieu-Daudé
2025-04-23 14:59 ` Pierrick Bouvier
2025-04-22 14:54 ` [RFC PATCH v4 15/19] qemu/target_info: Add target_aarch64() helper Philippe Mathieu-Daudé
2025-04-22 17:46 ` Richard Henderson
2025-04-22 18:21 ` Pierrick Bouvier
2025-04-22 14:54 ` [RFC PATCH v4 16/19] hw/arm/virt: Replace TARGET_AARCH64 -> target_aarch64() Philippe Mathieu-Daudé
2025-04-22 17:47 ` Richard Henderson
2025-04-22 18:22 ` Pierrick Bouvier
2025-04-22 14:54 ` [RFC PATCH v4 17/19] hw/core: Get default_cpu_type calling machine_class_default_cpu_type() Philippe Mathieu-Daudé
2025-04-22 17:58 ` Richard Henderson
2025-04-22 18:23 ` Pierrick Bouvier
2025-04-22 14:55 ` [RFC PATCH v4 18/19] hw/core: Introduce MachineClass::get_default_cpu_type() helper Philippe Mathieu-Daudé
2025-04-22 17:59 ` Richard Henderson
2025-04-22 18:24 ` Pierrick Bouvier
2025-04-22 14:55 ` [RFC PATCH v4 19/19] hw/arm/virt: Get default CPU type at runtime Philippe Mathieu-Daudé
2025-04-22 18:06 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b181a62c-c9cf-4d33-b694-b5099069ee79@linaro.org \
--to=pierrick.bouvier@linaro.org \
--cc=anjo@rev.ng \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).