From: Hannes Hering <hannes.hering@linux.vnet.ibm.com>
To: michael@ellerman.id.au
Cc: rdreier@cisco.com, alexs@linux.vnet.ibm.com,
linux-kernel@vger.kernel.org, ewg@lists.openfabrics.org,
linuxppc-dev@ozlabs.org, raisch@de.ibm.com,
ossrosch@linux.vnet.ibm.com
Subject: Re: [PATCH 2.6.31] ehca: Tolerate dynamic memory operations and huge pages
Date: Wed, 10 Jun 2009 10:54:50 +0200 [thread overview]
Message-ID: <200906101054.50822.hannes.hering@linux.vnet.ibm.com> (raw)
In-Reply-To: <1244592156.4680.5.camel@concordia>
Hi Michael,
On Wednesday 10 June 2009 02:02:36 Michael Ellerman wrote:
> For those of us who haven't read the HEA spec lately, can you give us
> some more detail on that? :)
first of all, please note that this patch is actually for the ehca infiniband
driver. The ehca driver uses an internal memory region, which is supposed to
contain all physical memory. A memory region maps a virtually contiguous
adapter address space to the physical or better absolute address space. The
limitation is that the memory region cannot map non-contiguous virtual adapter
address space. However, on ppc64 machines there is a feature to dynamically add
or remove memory to logical partitions during runtime. These operations scatter
the absolute memory so that the kernel memory has a non-contiguous layout. This
layout cannot be represented in a memory region. The purpose of this code is to
detect the memory layout so that the memory region can be made up of the
existing memory chunks. It also translates the kernel addresses to the memory
region address, which is needed for interaction with the HCA.
> How does it interact with kexec/kdump?
We never tested the ehca driver with kexec/kdump. This patch also doesn't
improve anything in this context.
> phys_to_abs() ? As below, or does it come from somewhere else?
You're right, actually that isn't needed on System p. On the other hand I
needed to choose an address type, which is the base of all mapping. The
"busmap" holds all addresses as absolute addresses. The absolute addresses can
then be converted in any other type (virt, phys).
Regards
Hannes
next prev parent reply other threads:[~2009-06-10 8:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-09 13:59 [PATCH 2.6.31] ehca: Tolerate dynamic memory operations and huge pages Hannes Hering
2009-06-10 0:02 ` Michael Ellerman
2009-06-10 8:54 ` Hannes Hering [this message]
2009-06-13 4:50 ` Roland Dreier
2009-06-16 7:08 ` Alexander Schmidt
2009-06-16 16:10 ` [ewg] " Roland Dreier
2009-06-17 6:41 ` Alexander Schmidt
2009-06-16 7:10 ` [PATCH 2.6.31 try 2] " Alexander Schmidt
2009-06-23 5:19 ` [ewg] " Roland Dreier
2009-06-23 8:11 ` Alexander Schmidt
2009-06-23 17:30 ` Roland Dreier
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=200906101054.50822.hannes.hering@linux.vnet.ibm.com \
--to=hannes.hering@linux.vnet.ibm.com \
--cc=alexs@linux.vnet.ibm.com \
--cc=ewg@lists.openfabrics.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=michael@ellerman.id.au \
--cc=ossrosch@linux.vnet.ibm.com \
--cc=raisch@de.ibm.com \
--cc=rdreier@cisco.com \
/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).