mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Haid <d.haid@gogi.tv>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andi Kleen <andi@firstfloor.org>, <linux-kernel@vger.kernel.org>
Subject: Re: Question about iommu on x86_64 and radeon driver.
Date: Tue, 31 May 2011 16:34:33 +0100	[thread overview]
Message-ID: <59be1730ec1660abeb7b4dc584510d34@admin.gogi.tv> (raw)
In-Reply-To: <20110531134519.GC14641@dumpdata.com>

> Noo.. It does, but the normal assumption of 'phys_to_virt' ==
> 'phys_to_bus' is
> not valid anymore. Think of a buffer (swiotlb) which has a pool
> of pages and when a PCI device wants a page, it hands one out. It 
> also has
> other functionality such as 'mapping' of an already allocated page. 
> If the
> PCI device asks the IOMMU (swiotlb) to map a page (and if you have
> 'swiotlb=force'
> the page provided has been allocated above 4GB and the device can 
> only handle
> up to 32-bit),

 Does the radeon driver allocate without DMA32, possibly above 4GB, ...

> then swiotlb gives out a page from its own pool. You now have
> two addresses: the one from the PCI pool (swiotlb) and the one you 
> already
> allocated.

 ... or does it allocate under 4GB but nevertheless get a page from
 the swiotlb pool?

> You are suppose to program your PCI card to read/write data to the
> page provided from the IOMMU (so the swiotlb), which means that it 
> won't
> write to the page you had allocated. Hence there are a calls, such as
> 'sync_page'..
> which will copy the contents from the swiotlb page to the one you had
> allocated
> (or vice-versa). This is called 'bounce buffer'.
>
> The radeon (and nouveau) don't have the code to call the 'sync_page', 
> and
> you wouldn't really want to do so - as it slows down the performance 
> of the
> machine. There exists another mechanism which is to allocate the 
> pages
> at the start, and not do mapping later one.

 Why can the radeon not simply allocate addresses under 4GB and not 
 request
 adresses from the iommu at all?

 I assume that if you request a page from the IOMMU, you are required to 
 do
 these sync_page calls (and that they get optimized away with a hardware 
 IOMMU?).

 So if the radeon uses the IOMMU but does not call sync_page even if 
 required to
 the code seems to be broken. If this is indeed the case would it not be 
 possible to
 simply add the sync_page calls for now (and thus fix the code), if it 
 is not
 difficult, and implement the method with more performance later?


  reply	other threads:[~2011-05-31 15:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-22 21:56 Daniel Haid
2011-05-23 22:05 ` Konrad Rzeszutek Wilk
2011-05-23 23:45   ` Daniel Haid
2011-05-24 15:50     ` Konrad Rzeszutek Wilk
2011-05-24 21:33       ` Daniel Haid
2011-05-25 12:58         ` Konrad Rzeszutek Wilk
2011-05-25 14:28           ` Daniel Haid
2011-05-24 22:48     ` Andi Kleen
2011-05-25 10:00       ` Daniel Haid
2011-05-25 12:57         ` Konrad Rzeszutek Wilk
2011-05-25 14:51           ` Daniel Haid
2011-05-25 20:21           ` Daniel Haid
2011-05-25 23:05             ` Andi Kleen
2011-05-27 15:48           ` Daniel Haid
2011-05-27 15:55             ` Konrad Rzeszutek Wilk
2011-05-27 22:20               ` Daniel Haid
2011-05-31 13:45                 ` Konrad Rzeszutek Wilk
2011-05-31 15:34                   ` Daniel Haid [this message]
2011-05-31 16:02                     ` Konrad Rzeszutek Wilk
     [not found]                       ` <0a8cb4bcad7fcf091a6bbe158323bba0@admin.gogi.tv>
2011-05-31 16:20                         ` Daniel Haid
     [not found]                         ` <20110531190412.GA21245@dumpdata.com>
2011-05-31 19:57                           ` Daniel Haid
2011-06-01 13:24                             ` Konrad Rzeszutek Wilk
2011-06-01 16:10                               ` Daniel Haid
2011-06-01 21:51                                 ` Andi Kleen
2011-06-01 21:58                                 ` Daniel Haid
2011-06-01 22:22                                   ` Andi Kleen
2011-06-03 17:31                                     ` [PATCH] tentative fix for radeon on systems >4GB without hardware iommu Daniel Haid
2011-06-03 20:44                                       ` Alex Deucher
2011-06-03 23:13                                         ` Konrad Rzeszutek Wilk
2011-06-06 17:45                                           ` Daniel Haid
2011-06-06 17:41                                         ` Daniel Haid
2011-06-06 19:08                                           ` Alex Deucher

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=59be1730ec1660abeb7b4dc584510d34@admin.gogi.tv \
    --to=d.haid@gogi.tv \
    --cc=andi@firstfloor.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®