Hello Peter M., [ ... ]
Another device that does some moderately complicated things with MemoryRegions is the hw/arm/armsse.c SoC, which has several CPUs and has some per-CPU devices. I think we have not thus far had a model of a board where different CPUs see radically different things (only ones where they can see minor differences), so you'll probably run into places where the APIs are a bit clunky (and we can perhaps have a go at making them a bit less so). What I would do is make the system_memory container be used by whatever is the "main" application processor SoC in your board. If the two SoCs really see absolutely different worlds with no shared devices at all, then you'll want to create a new empty container for the second SoC. If they do have some board-level shared devices, then you'll want to do something a little more complicated with aliases. If you find the SoC device models you're using hardcode use of system_memory or address_space_memory you should treat those as bugs to be fixed. Other loose ends (like monitor commands that assume the system address space) can be ignored: having those operate on the 'application processor' SoC is fine, I think.
On the CPU topic, I think we will need to change the GIC device to stop using qemu_get_cpu() in the CPU interface init routine and in the GIC realize routine, since this is global to the machine. I am having the same problem when trying to model a multi SoC board with a GIC device on each chip. What would be a good approach to loop only on the CPUs related to a GIC device ? Could we tag the CPUs and the GIC in some way to filter the unrelated CPUs ? Or pass a CPU list to the GIC device ? Thanks, C.
Overall, this is definitely doable but will involve a fair about of slogging through territory where nobody has yet broken a trail for you :-) -- PMM
