From: Joerg Roedel <joerg.roedel@amd.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: linux-kernel@vger.kernel.org, chrisw@sous-sol.org,
dwmw2@infradead.org, mingo@elte.hu
Subject: Re: [PATCH 0/10] x86: handle HW IOMMU initialization failure gracely
Date: Wed, 28 Oct 2009 14:21:19 +0100 [thread overview]
Message-ID: <20091028132119.GC5876@amd.com> (raw)
In-Reply-To: <1256712464-21472-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
On Wed, Oct 28, 2009 at 03:47:34PM +0900, FUJITA Tomonori wrote:
> If HW IOMMU initialization fails (Intel VT-d often does typically due
> to BIOS bugs), we fall back to nommu. It doesn't work for the majority
> since nowadays we have more than 4GB memory so we must use swiotlb
> instead of nommu.
>
> The problem is that it's too late to initialize swiotlb when HW IOMMU
> initialization fails. We need to allocate swiotlb memory earlier from
> bootmem allocator. Chris explained the issue in detail:
>
> http://marc.info/?l=linux-kernel&m=125657444317079&w=2
>
>
> The current x86 IOMMU initialization sequence is too complicated and
> handling the above issue makes it more hacky.
>
> This series changes x86 IOMMU initialization sequence to handle the
> above issue cleanly.
>
> The new x86 IOMMU initialization sequence are:
>
> 1. initializing swiotlb (and setting swiotlb to 1) in the case of
> (max_pfn > MAX_DMA32_PFN && !no_iommu). dma_ops is set to
> swiotlb_dma_ops or nommu_dma_ops.
>
> 2. calling the detection functions of all the IOMMUs
>
> 3. the detection function sets x86_init.iommu.iommu_init to the IOMMU
> initialization function (so we can avoid calling the initialization
> functions of all the IOMMUs needlessly).
>
> 4. if the IOMMU initialization function doesn't need to swiotlb then
> sets swiotlb to zero (e.g. the initialization is sucessful).
>
> 5. if we find that swiotlb is set to zero, we free swiotlb resource.
I started to test this patchset. It breaks the iommu=soft selection to
force using swiotlb usage. On my machine always the AMD IOMMU driver
gots selected and initialized.
Joerg
next prev parent reply other threads:[~2009-10-28 13:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-28 6:47 [PATCH 0/10] x86: handle HW IOMMU initialization failure gracely FUJITA Tomonori
2009-10-28 6:47 ` [PATCH 01/10] Add iommu_init to x86_init_ops FUJITA Tomonori
2009-11-09 20:02 ` Pekka Enberg
2009-11-09 20:11 ` FUJITA Tomonori
2009-11-10 4:45 ` Ingo Molnar
2009-10-28 6:47 ` [PATCH 02/10] Calgary: convert detect_calgary to use iommu_init hook FUJITA Tomonori
2009-10-28 13:38 ` Muli Ben-Yehuda
2009-10-28 6:47 ` [PATCH 03/10] GART: convert gart_iommu_hole_init " FUJITA Tomonori
2009-10-28 6:47 ` [PATCH 04/10] amd_iommu: convert amd_iommu_detect " FUJITA Tomonori
2009-10-28 6:47 ` [PATCH 05/10] intel-iommu: convert detect_intel_iommu " FUJITA Tomonori
2009-10-28 6:47 ` [PATCH 06/10] bootmem: refactor free_all_bootmem_core FUJITA Tomonori
2009-10-28 7:34 ` Ingo Molnar
2009-10-28 7:36 ` Ingo Molnar
2009-10-28 6:47 ` [PATCH 07/10] bootmem: add free_bootmem_late FUJITA Tomonori
2009-10-28 7:48 ` Ingo Molnar
2009-10-28 8:00 ` Tejun Heo
2009-10-28 11:38 ` Pekka Enberg
2009-10-28 12:12 ` Tejun Heo
2009-10-29 11:19 ` Pekka Enberg
2009-11-08 9:57 ` Ingo Molnar
2009-11-16 10:27 ` Joerg Roedel
2009-11-06 1:50 ` FUJITA Tomonori
2009-11-08 10:00 ` Ingo Molnar
2009-11-09 19:22 ` FUJITA Tomonori
2009-11-09 20:13 ` Pekka Enberg
2009-11-09 20:21 ` Pekka Enberg
2009-11-09 21:47 ` FUJITA Tomonori
2009-11-10 8:05 ` Pekka Enberg
2009-11-13 21:11 ` Chris Wright
2009-10-28 6:47 ` [PATCH 08/10] swiotlb: add swiotlb_free function FUJITA Tomonori
2009-10-28 6:47 ` [PATCH 09/10] swiotlb: export swiotlb_print_info FUJITA Tomonori
2009-10-28 6:47 ` [PATCH 10/10] x86: handle HW IOMMU initialization failure gracely FUJITA Tomonori
2009-10-28 13:21 ` Joerg Roedel [this message]
2009-10-29 8:27 ` [PATCH 0/10] " FUJITA Tomonori
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=20091028132119.GC5876@amd.com \
--to=joerg.roedel@amd.com \
--cc=chrisw@sous-sol.org \
--cc=dwmw2@infradead.org \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.