On Wed, 1 Oct 2025 at 22:59, Richard Henderson <[email protected]> wrote: > > On 10/1/25 14:37, Peter Xu wrote: > > I only have a very preliminary understanding on this, so please bare with > > me if I'll make silly mistakes... > > > > I was expecting QEMU provides both the global view (address_space_memory), > > and the per-vcpu view. > > My hypothesis is that separate views for each cpu doesn't make sense. > > In the true symmetric multiprocessor case, which is the vast majority of > everything we > emulate in QEMU, each processor has the exact same view(s).
This is not the case in general. Some CPUs have per-CPU devices which show up only for that CPU. Examples include the A9's per-CPU peripherals (which we don't currently model that way, but perhaps ought to) and some stuff in one of the M-profile boards. TCG registers its CPU listener with every AS because the information that TCG is caching that is stale is something it cares about for every AS the CPU has to deal with. HVF and KVM register their CPU listener only with address_space_memory because the information that those accelerators are caching is the details of RAM layout in the system, which in both cases the kernel imposes the limitation of being the same for every CPU. Similarly in target/arm's kvm_arm_register_device() we listen on address_space_memory because the thing we're listening for is "where has this device's MemoryRegion been put", and again the kernel imposes the requirement that the GIC (or whatever) is at the same location for all CPUs. The "global" view of address_space_memory and system_memory is a bit theoretically dubious because there's nothing saying all CPUs have to have some underlying mostly-the-same view of things. But in practice almost all systems do, plus KVM and HVF impose that world-model, so it's easier to retain this than try to think about how we would eliminate it. > In the rare asymmetric multiprocessor case, of which we have a few, we have a > couple of > clusters and within each cluster all cpus share the exact same view(s). > > Thus access to address spaces on a per-cpu basis makes sense, but allocating > them on a > per-cpu basis does not. Also, in general, per-CPU address spaces fits the rest of how we model memory-transaction-capable devices. The device (e.g. a DMA controller or similar) has a QOM property which takes a pointer to a MemoryRegion describing the view of the world that that device has; it then internally creates an AddressSpace whose purpose is to provide the APIs for making memory transactions into that MemoryRegion. cpu_address_space_init() is just some convenience wrapping around that. thanks -- PMM
