From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IU0yc-00071n-KN for qemu-devel@nongnu.org; Sat, 08 Sep 2007 10:07:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IU0ya-000710-OT for qemu-devel@nongnu.org; Sat, 08 Sep 2007 10:07:57 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IU0ya-00070x-Js for qemu-devel@nongnu.org; Sat, 08 Sep 2007 10:07:56 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IU0yZ-0003JO-WE for qemu-devel@nongnu.org; Sat, 08 Sep 2007 10:07:56 -0400 Received: by nf-out-0910.google.com with SMTP id d21so747815nfb for ; Sat, 08 Sep 2007 07:07:54 -0700 (PDT) Message-ID: Date: Sat, 8 Sep 2007 17:07:54 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework In-Reply-To: <200708292218.49078.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200708292139.31760.paul@codesourcery.com> <200708292218.49078.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On 8/30/07, Paul Brook 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?