qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Blue Swirl <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
Date: Wed, 29 Aug 2007 21:39:29 +0100	[thread overview]
Message-ID: <200708292139.31760.paul@codesourcery.com> (raw)
In-Reply-To: <f43fc5580708291000t1f28d6eawf635fb76afd3bf14@mail.gmail.com>

> 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

  reply	other threads:[~2007-08-29 20:39 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 [this message]
2007-08-29 21:18                     ` Paul Brook
2007-09-08 14:07                       ` Blue Swirl
2007-09-08 14:31                         ` Paul Brook
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=200708292139.31760.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).