> > 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_memor
On 06/11/2012 05:00 PM, Benjamin Herrenschmidt wrote:
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_
On Mon, 2012-06-11 at 17:29 -0500, Anthony Liguori wrote:
> I don't know that we really have bit masking done right in the memory API.
That's not a big deal:
> When we add a subregion, it always removes the offset from the address when
> it
> dispatches. This more often than not works out wel
Am 12.06.2012 00:00, schrieb Benjamin Herrenschmidt:
>>> system_memory
>>>alias -> pci
>>>alias -> ram
>>> pci
>>>bar1
>>>bar2
>>> pcibm
>>>alias -> pci (prio 1)
>>>alias -> system_memory (prio 0)
>>>
>>> cpu_physical_memory_rw() woul
On 06/11/2012 06:46 PM, Benjamin Herrenschmidt wrote:
On Mon, 2012-06-11 at 17:29 -0500, Anthony Liguori wrote:
When we add a subregion, it always removes the offset from the address when it
dispatches. This more often than not works out well but for what you're
describing above, it sounds lik
On Mon, 2012-06-11 at 20:33 -0500, Anthony Liguori wrote:
> On 06/11/2012 06:46 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2012-06-11 at 17:29 -0500, Anthony Liguori wrote:
> >
> >> When we add a subregion, it always removes the offset from the address
> >> when it
> >> dispatches. This more o
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
On 06/12/2012 01:29 AM, Anthony Liguori wrote:
>>
>> So it makes some amount of sense to use the same structure. For example,
>> if a device issues accesses, those could be caught by a sibling device
>> memory region... or go upstream.
>>
>> Let's just look at downstream transformation for a minute
On Tue, 2012-06-12 at 12:46 +0300, Avi Kivity wrote:
> > I think that transformation function lives in the bus layer
> > MemoryRegion. It's a bit tricky though because you need some sort of
> > notion of "who is asking". So you need:
> >
> > dma_memory_write(MemoryRegion *parent, DeviceState *ca
On 06/12/2012 07:37 PM, Benjamin Herrenschmidt wrote:
Not really no, we don't have proper DMA APIs to shoot from devices.
What the DMAContext patches provide is a generic dma_* API but if we are
going to get rid of DMAContext in favor of a (modified ?) MemoryRegion
I'd rather not expose that to
On Wed, 2012-06-13 at 15:57 -0500, Anthony Liguori wrote:
> I think pci_* wrappers is the right thing to do in the short term (and
> probably
> long term too).
Oh I agree absolutely. Same for vio, I'll do some wrappers. One
remaining question is where do the barriers go in that scheme...
I'll
On Wed, Jun 13, 2012 at 10:37:41AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2012-06-12 at 12:46 +0300, Avi Kivity wrote:
> > > I think that transformation function lives in the bus layer
> > > MemoryRegion. It's a bit tricky though because you need some sort of
> > > notion of "who is asking
On Thu, 2012-06-14 at 02:00 +0200, Edgar E. Iglesias wrote:
>
> TBH, I don't understand any of the "upstream" access discussion nor
> the specifics of DMA accesses for the memory/system bus accesses.
>
> When a device, like a DMA unit accesses the memory/system bus it,
> AFAIK, does it from a dif
On Thu, Jun 14, 2012 at 11:34:10AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-14 at 02:00 +0200, Edgar E. Iglesias wrote:
> >
> > TBH, I don't understand any of the "upstream" access discussion nor
> > the specifics of DMA accesses for the memory/system bus accesses.
> >
> > When a de
On Thu, 2012-06-14 at 04:03 +0200, Edgar E. Iglesias wrote:
> Thanks for the clarificatino Ben.
>
> I don't know much about PCI but in the embedded world I've never seen
> anything that resemblems what you describe. Devices at the bottom of
> the hierharcy (or at any location) that make acceses to
On Thu, Jun 14, 2012 at 12:16:45PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-14 at 04:03 +0200, Edgar E. Iglesias wrote:
> > Thanks for the clarificatino Ben.
> >
> > I don't know much about PCI but in the embedded world I've never seen
> > anything that resemblems what you describe.
On Thu, 2012-06-14 at 04:31 +0200, Edgar E. Iglesias wrote:
> > An AXI device might issue a cycle on the AXI portion, that can be
> > decoded by either a sibling AXI device ... or go up. In most cases
>
> No, it doesn't really go up.. This is where we disagree.
Well, not really indeed as the memo
On Thu, Jun 14, 2012 at 12:41:06PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-14 at 04:31 +0200, Edgar E. Iglesias wrote:
> > > An AXI device might issue a cycle on the AXI portion, that can be
> > > decoded by either a sibling AXI device ... or go up. In most cases
> >
> > No, it does
On Thu, 2012-06-14 at 05:17 +0200, Edgar E. Iglesias wrote:
> The CPU's MMU is a CPU local thing, it can be ignored in this context...
>
> Anyway, I might very well be missing or missunderstganding something so
> I'm not claiming I'm having the absolute "thruth" here but it seems to me
> like imp
< snip thread >
So I was looking at this accessor business. We already have them for
PCI. PAPR VIO already has its own as well.
That leaves us with various devices such as OHCI that can exist
on different bus types and use the lower-level "DMAContext" based
variant...
Now I'm keen to keep it (es
20 matches
Mail list logo
