[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] QOMification of AXI stream
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [RFC] QOMification of AXI stream |
Date: |
Tue, 12 Jun 2012 16:18:06 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 |
On 06/12/2012 03:58 PM, Peter Maydell wrote:
> 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.)
It would be a container region, and it would be unrelated to any other
regions held by the device (the device might not have any memory
regions; instead it would only be able to do dma).
>
>> 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.)
Correct. system_memory would be renamed cpu_memory, and would be cpu
local (since some systems allow each cpu to have a different memory map).
phys_map would be a cache for the memory map that can be seen through
that region; we might make it a field of MemoryRegion.
--
error compiling committee.c: too many arguments to function
- Re: [Qemu-devel] [RFC] QOMification of AXI streams, (continued)
- Re: [Qemu-devel] [RFC] QOMification of AXI streams, Avi Kivity, 2012/06/12
- Re: [Qemu-devel] [RFC] QOMification of AXI streams, Andreas Färber, 2012/06/11
- Re: [Qemu-devel] [RFC] QOMification of AXI streams, Benjamin Herrenschmidt, 2012/06/11
- Re: [Qemu-devel] [RFC] QOMification of AXI stream, Avi Kivity, 2012/06/12
- Re: [Qemu-devel] [RFC] QOMification of AXI stream, Edgar E. Iglesias, 2012/06/12
- Re: [Qemu-devel] [RFC] QOMification of AXI stream, Anthony Liguori, 2012/06/11
- Re: [Qemu-devel] [RFC] QOMification of AXI stream, Avi Kivity, 2012/06/12
- Re: [Qemu-devel] [RFC] QOMification of AXI stream, Peter Maydell, 2012/06/12
- Re: [Qemu-devel] [RFC] QOMification of AXI stream,
Avi Kivity <=
- Re: [Qemu-devel] [RFC] QOMification of AXI stream, Peter Maydell, 2012/06/12
- Re: [Qemu-devel] [RFC] QOMification of AXI stream, Avi Kivity, 2012/06/12
- Re: [Qemu-devel] [RFC] QOMification of AXI stream, Andreas Färber, 2012/06/12