On Fri, 20 Oct 2023 at 18:29, Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> wrote: > > Hi Peter, > > On 20/10/23 19:14, Peter Maydell wrote: > > So overall there are some places where figuring out the right > > replacement for qemu_get_cpu() is tricky, and some places where > > it's probably fairly straightforward but just an annoying > > amount of extra code to write, and some places where we don't > > care because we know the board model is not heterogenous. > > But I don't think "filter by CPU architecture type" is usually > > going to be what we want. > > Thank for these feedbacks. I agree the correct way to fix that > is a tedious case by case audit, most often using link properties. > > "we know the board model is not heterogeneous" but we want to > link such board/model altogether in a single binary, using common > APIs. This seems to me like a different thing -- just compiling the different boards into one binary. That should be fine: in this single-binary qemu, if you tell it -M foo that's an arm board then qemu_get_cpu() returns the CPUs that are created, and those will all be Arm. If you tell it -M bar that's a PPC board, then qemu_get_cpu() will return the CPUs that are created, and those will all be PPC. The assumptions of the code that's currently calling qemu_get_cpu() or using the first_cpu global won't be broken. It shouldn't need us to change a lot of code that we don't intend to try to use in a heterogenous-at-runtime setup. thanks -- PMM
