On 15/5/26 23:17, Cédric Le Goater wrote:
On 5/15/26 19:22, Pierrick Bouvier wrote:
On 5/15/2026 10:18 AM, Cédric Le Goater wrote:
On 5/15/26 19:00, Pierrick Bouvier wrote:
On 5/15/2026 9:29 AM, Cédric Le Goater wrote:
On 5/15/26 16:10, Philippe Mathieu-Daudé wrote:
aspeed_ast27x0.c models 2 similar SoC based on a 64-bit only
CPU (Cortex-A35), only available in the 64-bit binary.
If we build this file as common object, these SoCs become
available in both 32 and 64-bit binaries; however when running
the introspection test on the 32-bit binary, the init() method
tries to init the Cortex-A35 type -- although not realizing it
-- which is not available. This can be avoided by deferring the
CPU type initialization to the SoC DeviceRealize step (this is
safe because nothing uses the CPU type before, only the GIC
access them, just after their realization).
I understand this is a qtest workaround. Could we introduce
instead a (qtest_enabled() && 32-bit binary) helper ?
In general, it exposes a dependency issue in QOM type system.
In this case, we get a class depending on another one through
class_init. Moving this to realize seems like the best fix.
My feeling is that this goes against the best modeling practices
we have tried to put in place over the last decade.
In this case, adding the workaround you suggested might be the best
approach indeed.
What was said is "we'll soon have a single ARM binary able to run all
all CPU types, no need to make pointless changes due to a test that
won't fail because all CPU types available in this binary". But we
are still 1 step from it -- removing the 32-bit binary -- so I'll add
Cédric's workaround.
Well, if we want to make progress, let's at least add a comment
for better fix later.
C.
