| Message ID | 20250402222334.66511-1-philmd@linaro.org |
|---|---|
| Headers | show |
| Series | arm: Spring header cleanups | expand |
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). > > Philippe Mathieu-Daudé (13): > target/arm/cpu-features: Include missing 'cpu.h' header > target/arm/qmp: Include missing 'cpu.h' header > target/arm/kvm: Include missing 'cpu-qom.h' header > target/arm/hvf: Include missing 'cpu-qom.h' header > hw/arm: Remove unnecessary 'cpu.h' header > target/arm: Restrict inclusion of 'multiprocessing.h' > target/arm: Move some definitions from 'cpu.h' to 'multiprocessing.h' > hw/arm: Include missing 'target/arm/gtimer.h' header > target/arm: Extract PSCI definitions to 'psci.h' > target/arm: Extract feature definitions to 'cpu_has_feature.h' header > target/arm: Add arm_cpu_has_feature() helper > hw/arm/realview: Replace arm_feature() -> arm_cpu_has_feature() > hw/arm/virt-acpi: Replace arm_feature() -> arm_cpu_has_feature() > Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
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.
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. Single binary effort is just a milestone toward heterogeneous emulation.
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.