Re: [Qemu-devel] [RFC] QOMification of AXI streams

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.