All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alok Kataria <akataria@vmware.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	linux-acpi <linux-acpi@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Petr Vandrovec <petr@vmware.com>
Subject: Re: swiotlb detection should be memory hotplug aware ?
Date: Mon, 15 Mar 2010 10:22:49 -0700	[thread overview]
Message-ID: <1268673769.28506.1.camel@ank32> (raw)
In-Reply-To: <4B9B01F5.3000807@linux.intel.com>

Hi Andi, 

On Fri, 2010-03-12 at 19:09 -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
> more efficiently (the current way is pretty dumb)  I need to repost that.

Can you please send me any pointers to that patch series. Also am just
curious to know about any merge plans for that patchkit.

Thanks,
Alok
> 
> With that it would be relatively easy to do I think.
> 
> -Andi


  reply	other threads:[~2010-03-15 17:22 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 [this message]
2010-03-16  0:51   ` [LKML] " Konrad Rzeszutek Wilk
2010-03-16  1:33     ` FUJITA Tomonori
2010-03-16 12:45       ` [LKML] " Konrad Rzeszutek Wilk
2010-03-17 22:48         ` 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=1268673769.28506.1.camel@ank32 \
    --to=akataria@vmware.com \
    --cc=ak@linux.intel.com \
    --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 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.