From: Paul Brook <paul@codesourcery.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
Date: Sat, 8 Sep 2007 15:31:24 +0100 [thread overview]
Message-ID: <200709081531.25197.paul@codesourcery.com> (raw)
In-Reply-To: <f43fc5580709080707mc68c9a6m92f79e76d1972f7d@mail.gmail.com>
> 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
I thought device selection was separate from the 28-bit SBus slave address
space. ie. each device has exclusive ownership of the whole 28-bit address
space, and it's effectively just multiplexing per-slave busses over a single
electrical connection.
> - 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.
IIUC devices never register addresses on the master bus. The only thing that
responds on that bus is the IOMMU.
> 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.
PCI shouldn't need a dual bus setup. You just have one bus for PCI and one bus
for CPU/memory.
IMHO the whole point of having a generic bus infrastructure is that we can
define address mapping in terms of [asymmetric] translations from one bus
address space to another. This isolates teh device from needing to care about
bridges and IOMMu.
If we're assuming 1:1 or symmetric address space mapping there doesn't seem
much point modelling separate busses. Instead push everything into the device
registration and DMA routines.
Paul
next prev parent reply other threads:[~2007-09-08 14:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-14 19:48 [Qemu-devel] PATCH, RFC: Generic DMA framework Blue Swirl
2007-08-16 18:18 ` [Qemu-devel] " Blue Swirl
2007-08-16 19:58 ` malc
2007-08-19 17:46 ` Blue Swirl
2007-08-24 19:40 ` Blue Swirl
2007-08-24 20:18 ` Paul Brook
2007-08-24 23:33 ` Fabrice Bellard
2007-08-25 0:29 ` Paul Brook
2007-08-26 11:30 ` Fabrice Bellard
2007-08-26 17:54 ` Blue Swirl
2007-08-28 19:03 ` Blue Swirl
2007-08-28 19:43 ` Paul Brook
2007-08-29 17:00 ` Blue Swirl
2007-08-29 20:39 ` Paul Brook
2007-08-29 21:18 ` Paul Brook
2007-09-08 14:07 ` Blue Swirl
2007-09-08 14:31 ` Paul Brook [this message]
2007-09-08 14:53 ` Blue Swirl
2007-09-08 16:03 ` Paul Brook
2007-09-15 16:16 ` Blue Swirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200709081531.25197.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.