Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework

[Paul Brook]

> This is a bit mysterious for me too. SBus address space is 28 bits
> (256MB). Usually each slot maps to a different area. So the CPU sees
> one slot for example at 0x3000 0000 and other at 0x4000 0000.
>
> IOMMU can map max 2G of memory, usually a 32 or 64MB region. For the
> devices, this device virtual memory access (DVMA) space exists at the
> top of address space (for example 0xfc00 0000). Each page can map to a
> different address. But these mappings can not be seen from CPU, for
> example the boot prom is located at 0xffd0 0000. I wonder how the
> devices access the DVMA space in case of >256M DVMA.
>
> The device can't obviously supply the address bits 28-31, I don't know 
> where they come from (=1?). But from tracing Linux I'm pretty sure
> that the bus address can be 0 disregarding the higher bits and also
> the device (or device FCode prom more likely) can exist at that
> location. How? Maybe IOMMU does not see CPU accesses at all and the
> devices see neither each other nor themselves, so it's not a really a
> shared bus?

I can't find a copy of the SBus specification, so I'm guessing how this fits 
together.

The key bit is that SBus controller performs device selection. c.f. PCI and 
ISA where each device does full address decoding.
What information I've found indicates that SBus supports an unlimited number 
of slave devices, and master devices use a 32-bit virtual address space.

This leads me to the conclusion that it's as if each slave device is on its 
own 28-bit bus, and the sbus devices master transactions go via the IOMMU 
onto the CPU bus. From there they may be routed back to an SBus device.
Actual implementation may need to do some short-circuiting to prevent 
deadlock, so I'm not entirely sure about this.

If this is the case, it means we don't need anything complicated. Devices map 
themselves straight into the system address space at the appropriate slot 
address (no plug-n-play to worry about), and device "DMA" goes via the IOMMU.

Because devices do not do address decoding I suspect this isn't going to 
nicely fit into a generic bus framework that would work for most systems.

Paul