On 4/3/25 12:31, Philippe Mathieu-Daudé wrote:
On 3/4/25 20:22, Pierrick Bouvier wrote:
On 4/2/25 15:23, Philippe Mathieu-Daudé wrote:
This series is more useful for heterogeneous emulation preparation
than single binary, because it allows non-ARM hw/ code to configure
ARM cores, so not using target-specific APIs. I figured some
patches could be useful to Pierrick "build hw/arm once" series (in
particular arm_cpu_has_feature).
I'm ok with the cleanup part, as I sent a reviewed-by.
However, I'm not sure in which context non-ARM hw/ code will really need
to do it. It would be better if we stick to mandatory changes for now,
instead of anticipating future needs, which might be real or not.
We can implement those changes only as part of a series that really
needs it.
I understand your view. I had to rebase these now old patches, and
figured it will cost me less if I get them merged, rather than
keeping rebasing them for 4 or 5 releases.
Sure, that's the best approach. For the reviewer, it's not obvious when
you implemented this though, so the only question we can ask is "Why is
that needed?".
Single binary effort is just a milestone toward heterogeneous emulation.
Yes. That said, it does not change the fact that anticipating needs
(i.e. not explicitely required to compile/execute right now) can detour
us from the goal, whether it's the single binary, heterogeneous
emulation, or any feature we want to add to QEMU.
In the context of this series, it's still not obvious for me why a piece
of hardware not related to Arm would poke internal registers to detect
if a feature is implemented or not. Thus, it's not obvious why we need
to expose that now. If we don't have an answer to that, I suggest to
postpone this part of the series until we get a real use case.
For the cleanup part, as I mentioned before, I'm totally ok with it.
