Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Maydell]

On 13 May 2014 12:07, Peter Crosthwaite <address@hidden> wrote:
> On Tuesday, May 13, 2014, Peter Maydell <address@hidden> wrote:
>> 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?

Well, the DMA API generally can mostly remain as-is: that's
the API for devices which are bus-masters to use to do the
read/write/etc operations. So that kind of device would take
a MemoryRegion* representing its view of the world, convert it
to an AddressSpace in its realize method, and then use the AS
to do DMA as required via the existing API.

I haven't looked closely at how we handle IOMMUs currently...

>> 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.

This seems confused about who creates the address spaces.
It doesn't seem very consistent for the object in the middle
of the stack (the SoC container) to create them and pass
them both up to the CPU and down to the board. The nice
thing about "MRs everywhere" is the consistency effect:
it's always the lowest layer that creates the container and
hands it up to the layer above.

> 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?

I can't currently see any reason why it wouldn't work. This will
mean we'll typically end up with several ASes which are duplicates
(eg if all CPUs in the system have the same view of memory then
they'll have their own ASes which all have the same MR root)
but IIRC from discussion earlier this isn't a big deal.

thanks
-- PMM