From: Chris Wright <chrisw@sous-sol.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Chris Wright <chrisw@sous-sol.org>,
David Woodhouse <dwmw2@infradead.org>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] allow fallback to swiotlb on hw iommu init failures
Date: Mon, 26 Oct 2009 09:26:37 -0700 [thread overview]
Message-ID: <20091026162637.GA27699@sequoia.sous-sol.org> (raw)
In-Reply-To: <87hbtmy6jc.fsf@basil.nowhere.org>
* Andi Kleen (andi@firstfloor.org) wrote:
> Chris Wright <chrisw@sous-sol.org> writes:
>
> > This short series gives us the ability to allocate the swiotlb and then
> > conditionally free it if we discover it isn't needed. This allows us to
> > put swiotlb to use when the hw iommu fails to initialize properly.
> >
> > This needs some changes to the bootmem allocator to give the ability to
> > free reserved bootmem directly to the page allocator after bootmem is
> > torn down.
>
> You forgot to state what motivated you to that change?
I thought I did ;-) Here's another more verbose attempt:
The HW IOMMU, for example Intel VT-d, may fail initialization (typically
due to BIOS bugs). In that case the existing fallback is nommu, which is
clearly insufficient for many boxen which need some bounce buffering if
there is no HW IOMMU. The problem is that at the point of this failure
the decision to allocate and initialize the swiotlb has long since past.
There are 4 ways to handle this:
1) Give up and panic the box. This is not a user friendly option since
the box will boot and function fine (minus any isolation gained from the
HW IOMMU) if there is either not much phys mem or an swiotlb.
2) Do the discovery that causes the initialization failure earlier so
that HW IOMMU detection fails. Compilcated by the HW IOMMU's use of the
run time env that includes a real allocator and PCI enumeration, etc.
3) Allow the swiotlb to be allocated later in pci_iommu_init() instead
of early in pci_iommu_alloc(), IOW don't use bootmem for the swiotlb.
This is possible, although it will hit 2 limitations. The first is any
possible fragmentation that limits the availability of a 64M region
by the time this runs. The second is that x86 has MAX_ORDER of 11,
so at most we can allocate a 4M region from the page allocator which is
inusufficient for swiotlb.
4) Allow the swiotlb to be allocated in pci_iommu_alloc(), but not
initialized until pci_iommu_init(). This allows using bootmem allocator
to reserve a nice large contiguous chunk of memory, but requires some
way to give that memory back in the case that a HW IOMMU is properly
both detected and initialized (else it'd be a 64M memory leak for
effectively all HW IOMMU enabled boxen).
This series implements the fourth option.
thanks,
-chris
next prev parent reply other threads:[~2009-10-26 16:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-23 1:21 [RFC PATCH 0/3] allow fallback to swiotlb on hw iommu init failures Chris Wright
2009-10-23 1:21 ` [RFC PATCH 1/3] [RFC PATCH] bootmem: refactor free_all_bootmem_core Chris Wright
2009-10-23 1:22 ` [RFC PATCH 2/3] [RFC PATCH] bootmem: add free_bootmem_late Chris Wright
2009-10-23 1:22 ` [RFC PATCH 3/3] [RFC PATCH] iommu: allow fallback to swiotlb upon hw iommu initialization failure Chris Wright
2009-10-23 5:51 ` [RFC PATCH 0/3] allow fallback to swiotlb on hw iommu init failures FUJITA Tomonori
2009-10-23 16:39 ` Chris Wright
2009-10-24 3:06 ` FUJITA Tomonori
2009-10-24 6:57 ` Chris Wright
2009-10-28 6:53 ` FUJITA Tomonori
2009-10-26 7:10 ` Andi Kleen
2009-10-26 16:26 ` Chris Wright [this message]
2009-10-26 21:56 ` Andi Kleen
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=20091026162637.GA27699@sequoia.sous-sol.org \
--to=chrisw@sous-sol.org \
--cc=andi@firstfloor.org \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--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