On Tuesday, May 13, 2014, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 13 May 2014 00:27, Peter Crosthwaite > <peter.crosthwa...@xilinx.com<javascript:;>> > wrote: > > Ok so here's my plan: > > This generally all sounds good to me. A slight nit: > > > QOMify address spaces. So they can be instantiated, reffed etc. > > completely aside from the hotplug discussion this greatly helps > > connecting bus master devices using proper QOM links. E.G. using > > machine-set link properties rather &address_space_memory everywhere. > > I'm not sure that the thing a bus master exposes to be connected > up should be an AddressSpace -- I think it should be a MemoryRegion > (more precisely, the code creating the bus-master should create > a MemoryRegion and pass it to the bus-master device). > > So this does alter the current thinking slightly, in that the current DMA API has devices reffing addr spaces. I think the idea there is to provide iommu capability? > Consider a board model which puts together some RAM and > devices. It ought to have the same interface for passing this > up to the CPU whether it's doing so directly or via some SoC > container device. For the SoC container case, this has to be > by passing a MemoryRegion, since the SoC will want to add > some devices of its own to create a combined board+SoC view to > pass to the CPU object proper. My thinking here is SoC can create an address space for it's masters to master (cpu included) and add slave peripherals to its root MR. Both AS and MR are then exposed to board level by the SoC for board level master and slaves resp. > So for consistency the interface > for passing things to the CPU should also be a MemoryRegion > (which the CPU then turns into an AddressSpace for its own > internal use.) > > Although if we pull this off without major change its definitely preffered by me. AS vs MR confusion is an issue. Can we realistically convert all master AS refs to MR? Regards Peter > thanks > -- PMM > >
