qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [RFC] QOMification of AXI stream
Date: Tue, 12 Jun 2012 13:58:02 +0100

On 11 June 2012 18:31, Avi Kivity <address@hidden> wrote:
> On 06/11/2012 06:01 PM, Anthony Liguori wrote:
>> Perhaps we should just make MemoryRegion work in both directions?

> The other direction is currently cpu_physical_memory_rw().  We do need
> to support issuing transactions from arbitrary points in the memory
> hierarchy, but I don't think a device's MemoryRegion is the right
> interface.  Being able to respond to memory transactions, and being able
> to issue them are two different things.

...they're just opposite sides of the same interface, though,
really. For instance you could say that any memory transaction
master (cpu, dma controller, whatever) should take a single
MemoryRegion* and must issue all its memory accesses to that MR*.
(obviously that would usually be a container region.)

> In fact we will probably have to add more details to the memory
> hierarchy.  Currently (for example) we model the memory hub passing
> transactions destined for the various pci windows to the pci bus, but we
> don't model the memory hub receiving a pci-initiated transaction and
> passing it to the system bus.  We simply pretend it originated on the
> system bus in the first place.  Perhaps we need parallel hierarchies:
>
>   system_memory
>      alias -> pci
>      alias -> ram
>   pci
>      bar1
>      bar2
>   pcibm
>      alias -> pci  (prio 1)
>      alias -> system_memory (prio 0)
>
> cpu_physical_memory_rw() would be implemented as
> memory_region_rw(system_memory, ...) while pci_dma_rw() would be
> implemented as memory_region_rw(pcibm, ...).  This would allow different
> address transformations for the two accesses.

Ideally system_memory shouldn't exist at all. Anything
which can issue transactions should do it by exposing
a suitable interface which the system model can then
just wire up suitably. Obviously mostly that's going
to be "all these devices go here in the memory map and
that view of the world is what all the CPUs see", but
we shouldn't have a globally accessible and implicitly
used address space IMHO.

(For instance, the right way to model per-CPU devices
is to have each individual CPU core expose its transaction
master, and then you wire the per-CPU devices up only
to their corresponding CPU.)

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]