qemu-devel
[Top][All Lists]
Advanced

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

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


From: Blue Swirl
Subject: Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
Date: Sat, 8 Sep 2007 17:07:54 +0300

On 8/30/07, Paul Brook <address@hidden> wrote:
> > 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.
>
> Further searching by google suggests I may be wrong.
>
> The alternative is that the controller maps the 32-bit VA onto a device
> select+28-bit address, using some as-yet undiscovered mechanism.
> There are then a couple of different options for how the CPU/memory bus is
> accessed:
> a) The IOMMU is one or more slave devices, than feed the 28-bit address
> possibly plus a few other bits from the device ID into the translation table.
> This effectively allows you to map a proportion of the SBus 32-bit master VA
> space onto CPU address space via the IOMMU, and map the remainder onto
> devices on the same bus. For a system with <=8 slots per bus a fixed mapping
> using the first 2G as 256Mb for each slot and the top 2G for IOMMU is
> entirely feasible.
> b) The 32-bit SBus VA is looked up directly into the IOMMU. Each IOMMU entry
> can refer to either a CPU address, or a device+28-bit address on the local

>From DMA2.txt, NCR89C100.txt, NCR89C105.txt and turbosparc.pdf I
gather the following:
- CPU and IOMMU always perform slave accesses
- Slave accesses use the 28-bit address bus to select the device
- Slave accesses are not translated by IOMMU
- NCR master devices (Lance, ESP) use an internal DREQ-style signal to
indicate their need for DMA to their DMA controller
- Master accesses use the 32-bit SBus data signals for both address and data
- DMA controller is the master for NCR89C100+NCR89C105 combination
- Master accesses are translated and controlled by IOMMU
- Slave devices may or may not support master access cycles (not
supported in the NCR case)
- IOMMU can give direct bus access for "intelligent masters" (no devices known)

We could model this using two buses: A slave bus between the CPU and
the devices, and a master bus between devices and IOMMU. The slave bus
translates the 36-bit CPU/memory bus addresses to 28-bit SBus bus
addresses. The master bus uses IOMMU to translate 32-bit DVMA
addresses to 36-bit CPU/memory bus addresses. Slave devices are
connected to the slave bus and DREQs. Master devices and DMA
controllers take the DREQs and both buses. Devices register the
address ranges they serve on each bus.

On Sun4c (without IOMMU) there would be just one bus for both purposes
(with the MMU quirk).

For the Sparc64 PCI bus which has an IOMMU, a similar dual bus
arrangement would be needed. On PC/PPC systems the two buses would be
again one.

Maybe even the IO port access and MMIO could be unified (one generic
bus for both)? That could simplify the device registration.

Alternatively, the generic bus could support several access modes, so
there would be no need for many virtual buses.

Comments?




reply via email to

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