[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework |
Date: |
Wed, 29 Aug 2007 21:39:29 +0100 |
User-agent: |
KMail/1.9.7 |
> 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
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, (continued)
- [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, Blue Swirl, 2007/08/24
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, Paul Brook, 2007/08/24
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, Fabrice Bellard, 2007/08/24
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, Paul Brook, 2007/08/24
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, Fabrice Bellard, 2007/08/26
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, Blue Swirl, 2007/08/26
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, Blue Swirl, 2007/08/28
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, Paul Brook, 2007/08/28
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, Blue Swirl, 2007/08/29
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework,
Paul Brook <=
- Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework, Paul Brook, 2007/08/29