From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: ak@linux.intel.com, akataria@vmware.com, lenb@kernel.org,
x86@kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, petr@vmware.com
Subject: Re: [LKML] Re: [LKML] Re: swiotlb detection should be memory hotplug aware ?
Date: Tue, 16 Mar 2010 08:45:56 -0400 [thread overview]
Message-ID: <20100316124556.GA25340@phenom.dumpdata.com> (raw)
In-Reply-To: <20100316103259E.fujita.tomonori@lab.ntt.co.jp>
On Tue, Mar 16, 2010 at 10:33:20AM +0900, FUJITA Tomonori wrote:
> On Mon, 15 Mar 2010 20:51:40 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>
> > On Fri, Mar 12, 2010 at 07:09:41PM -0800, Andi Kleen wrote:
> > > , Alok Kataria wrote:
> > >
> > > Hi Alok,
> > >
> > >> Hi,
> > >>
> > >> Looking at the current code swiotlb is initialized for 64bit kernels
> > >> only when the max_pfn value is greater than 4G (MAX_DMA32_PFN value).
> > >> So in cases when the initial memory is less than 4GB the kernel boots
> > >> without enabling swiotlb, when we hotadd memory to such a kernel and go
> > >> beyond the 4G limit, swiotlb is still disabled. As a result when any
> > >> 32bit devices start using this newly added memory beyond 4G, the kernel
> > >> starts spitting error messages like below or in some cases it causes
> > >> kernel panics.
> > >
> > > Yes seems like a real problem.
> > >
> > >>
> > >> 1. Enable swiotlb for all 64bit kernels which have memory hot-add
> > >> support.
> > >
> > > I don't think that's a good idea. It would enable it everywhere on
> > > distributions which compile with hotadd. Need (2)
> > >
> > >> 2. Instead of checking the max_pfn value in pci_swiotlb_detect, check
> > >> for max_hotpluggable_pfn (or some such) value. Though I don't see such a
> > >> value readily available. I could parse the SRAT and get hotplug memory
> > >> information but that will make swiotlb detection logic a little too
> > >> complex. A quick look around srat_xx.c files and the acpi_memhotplug
> > >> module didn't find any useful API that could be used directly either.
> > >> So was wondering if any of you are aware of an easy way to get such
> > >> information ?
> > >
> > > I have a patchkit to revamp the SRAT parsing to store the hotadd information
> >
> > There is a late mechanism to do kickoff the SWIOTLB. Perhaps the hot-add
> > could use swiotlb_init_late and start up the SWIOTLB?
>
> I guess that you are talking about
> swiotlb_late_init_with_default_size(), which IA64 uses. However, you
> can use swiotlb_late_init_with_default_size() only before we
> initialize devices. Making it work after initializing devices is not
> so easy, I think (that is, we need to change dma_ops).
That is a good point. Especially if we have some outstanding DMA pages
allocated via dma_alloc_coherent.
I thought that the machines that have hot-add memory they have their
own fancy IOMMU. For example the IBM x3955 (and its family) utilize the
Calgary IOMMU. The HP boxes utilize the Intel VT-D (or the AMD
equivalant).
So is this mostly specialized in the areas of virtualized guests? (Xen
PV guests with PCI passthrough suffer the same problem, btw).
next prev parent reply other threads:[~2010-03-16 15:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-13 2:07 swiotlb detection should be memory hotplug aware ? Alok Kataria
2010-03-13 3:09 ` Andi Kleen
2010-03-15 17:22 ` Alok Kataria
2010-03-16 0:51 ` [LKML] " Konrad Rzeszutek Wilk
2010-03-16 1:33 ` FUJITA Tomonori
2010-03-16 12:45 ` Konrad Rzeszutek Wilk [this message]
2010-03-17 22:48 ` [LKML] " Alok Kataria
2010-07-20 22:14 ` Alok Kataria
2010-07-21 4:58 ` FUJITA Tomonori
2010-07-21 17:13 ` Alok Kataria
2010-07-21 23:44 ` FUJITA Tomonori
2010-07-22 0:03 ` FUJITA Tomonori
2010-07-22 18:34 ` Alok Kataria
2010-07-23 14:22 ` Konrad Rzeszutek Wilk
2010-07-23 14:33 ` Andi Kleen
2010-07-23 14:59 ` Konrad Rzeszutek Wilk
2010-07-23 15:23 ` Andi Kleen
2010-07-28 10:10 ` FUJITA Tomonori
2010-07-28 11:09 ` Andi Kleen
2010-07-28 14:20 ` 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=20100316124556.GA25340@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=ak@linux.intel.com \
--cc=akataria@vmware.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=petr@vmware.com \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).