On Tue, 2012-06-12 at 03:04 +0200, Andreas Färber wrote: > That's not quite the way we're modelling it yet as shown by Avi above, > there is no CPU address space, only a "system" address space.
That can be considered as roughly equivalent for now, though it might become problematic when modelling crazy embedded setups, I think at this stage, we can consider that all the CPUs have the same view of the world which is more/less the "system bus". > The way we're modelling it today is shoving everything into a global > machine-level adress space which many devices access themselves via > get_system_memory() and get_system_io() because there's no easy way to > pass it to them except for exposing their struct and setting a field > before qdev_init_nofail(). > http://git.qemu.org/?p=qemu.git;a=blob;f=hw/ppc_prep.c;h=be2b26830deed1f728c01aa8f0582b63540919a8;hb=HEAD#l588 > > Can't each CPUState get a MemoryRegion for its CPU address space, which > then can have subregions/aliases for the one system_memory with its > subregions for PCI host bridge etc.? Then there's no need any more to > have a cpu_physical_memory_rw(), is there? I think that's less urgent. The problem is really when going from that "system bus" down to various IO busses, whether they are AXI, PLB4/5/6, PCI or PCI behind any of the previous ones, etc.... There's potentially translation happening when crossing those bridges, though most of the time, this can be represented in the form of one or more "window" that forward a given region of the parent bus down to the child bus with an offset. >From there, the child bus will itself potentially have a collection of stacked up bridges that may or may not translate or may or may not convey portions of that address space. The rules for translation "upstream" are similar, except that often you have an iommu on the way (though potentially there could be one on the way downstream as well). The "MemoryRegion" structure is a bit of an odd way to represent this but it could be re-used, though I reckon we should probably generalize the concept of "offset". Cheers, Ben.
