From: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] iommu: Split iommu_unmaps
Date: Thu, 07 Nov 2013 16:37:27 +0000 [thread overview]
Message-ID: <1383842247.27315.117.camel@shinybook.infradead.org> (raw)
In-Reply-To: <20130524171401.14099.78694.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2100 bytes --]
On Fri, 2013-05-24 at 11:14 -0600, Alex Williamson wrote:
> iommu_map splits requests into pages that the iommu driver reports
> that it can handle. The iommu_unmap path does not do the same. This
> can cause problems not only from callers that might expect the same
> behavior as the map path, but even from the failure path of iommu_map,
> should it fail at a point where it has mapped and needs to unwind a
> set of pages that the iommu driver cannot handle directly. amd_iommu,
> for example, will BUG_ON if asked to unmap a non power of 2 size.
>
> Fix this by extracting and generalizing the sizing code from the
> iommu_map path and use it for both map and unmap.
>
> Signed-off-by: Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Ick, this is horrid and looks like it will introduce a massive
performance hit.
Surely the answer is to fix the AMD driver so that it will just get on
with it and unmap the {address, range} that it's asked to map?
And fix the generic iommu_map() code while we're at it, to do it the
same way.
IOTLB flushes are *slow*, and on certain hardware with
non-cache-coherent page tables even the dcache flush for the page table
is slow. If you deliberately break it up into individual pages and do
the flush between each one, rather than just unmapping the range, you
are pessimising the performance quite hard.
A while back, I went through the Intel IOMMU code to make sure it was
doing this right — it used to have this kind of bogosity with repeated
per-page cache and IOTLB flushes *internally*, and the resulting
performance improvement was shown at http://david.woodhou.se/iommu.png
You will basically be undoing that work, by ensuring that the low-level
driver never *sees* the full range.
If the AMD driver really can't handle more than one page at a time, let
it loop for *itself* over the pages.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org Intel Corporation
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2013-11-07 16:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-24 17:14 [PATCH] iommu: Split iommu_unmaps Alex Williamson
[not found] ` <20130524171401.14099.78694.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-06-05 16:39 ` Alex Williamson
2013-11-07 16:37 ` David Woodhouse [this message]
[not found] ` <1383842247.27315.117.camel-Fexsq3y4057IgHVZqg5X0TlWvGAXklZc@public.gmane.org>
2013-11-11 23:09 ` Alex Williamson
[not found] ` <1384211375.22415.69.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2013-11-20 14:29 ` David Woodhouse
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=1383842247.27315.117.camel@shinybook.infradead.org \
--to=dwmw2-wegcikhe2lqwvfeawa7xhq@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.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).