On Tue, 20 Feb 2024 at 19:28, Philippe Mathieu-Daudé <phi...@linaro.org> wrote: > cpu_interrupt() doesn't scale well with heterogenous machines > because its mask is target specific (defined in target/ARCH/cpu.h). > > While it is (often...) used by target-specific hw to notify cpu, > there is no restriction to use such target-specific hw in a > heterogeneous setup, where it'd still target the same kind of > target cpus.
When would this target-specific hw call cpu_interrupt() on a CPU which is not of that target architecture? For instance, in the typhoon code you change in patch 2, the CPUState argument to cpu_interrupt() and cpu_reset_interrupt() is always that of one of the 4 CPUs pointed to by the TyphoonState struct, which are guaranteed to be Alpha CPUs. In some hypothetical world where this machine type had an Arm board-management CPU on it as well, that CPU would not be one of the ones pointed to by the TyphoonState struct, which would still all be Alpha. I can see that you would run into slight awkwardness on a device that wanted to do this same kind of thing on two CPU types at once, just because the defines are in cpu.h and you can't #include them both at once. But are we going to in practice have those on a heterogenous machine? > The Alpha Typhoon HW is unlikely to be used heterogeneously, > but it is the simplest case I found to illustrate how I plan > to remove cpu_interrupt() calls from hw/: use the QDev GPIO API. I do generally think that it's probably nicer design to have cpu_interrupt() be internal to target/foo (it's how arm does it, except for a handful of calls in obsolete SoC models). But I think it might be helpful if you could give a description of what the immediate issue is that means that we need to do this cleanup to progress with the heterogenous machine work (and to what extent we can leave existing code in old non-heterogenous board and device models alone). thanks -- PMM
