From: Arnd Bergmann <arnd@arndb.de>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 06/18] ARM: LPAE: Introduce the 3-level page table format definitions
Date: Mon, 25 Oct 2010 15:25:08 +0200 [thread overview]
Message-ID: <201010251525.09002.arnd@arndb.de> (raw)
In-Reply-To: <1288007977.14756.41.camel@e102109-lin.cambridge.arm.com>
On Monday 25 October 2010, Catalin Marinas wrote:
> On Mon, 2010-10-25 at 12:15 +0100, Arnd Bergmann wrote:
> > On Monday 25 October 2010, Catalin Marinas wrote:
> >
> > Since the PGD is so extremely small, would it be possible to fold it
> > into the mm_context_t in order to save an allocation?
> > Or does the PGD still require page alignment?
>
> There are alignment restrictions, though not to a page size. Given the
> TTBR0 access range of the full 4GB (TTBCR.T0SZ = 0), the alignment
> required is 64 (2^6). We get this for the slab allocator anyway when the
> L1_CACHE_SHIFT is 6 but I could make this requirement explicit by
> creating a kmem_cache with the required alignment.
I think you only need to set ARCH_MIN_TASKALIGN for that, which
also defaults to L1_CACHE_SHIFT.
> > Do you also have patches to allow 40-bit virtual space? I suppose we
> > will need that for KVM support in the future.
>
> I'm not sure how these would look like since the architecture is 32-bit
> (and I'm not familiar with KVM). With the MMU disabled, you can't access
> beyond the 4GB space anyway. KVM could use something like the pfn but in
> the virtual space.
>
> Cortex-A15 comes with both LPAE and Virtualisation Extensions, so the
> latter could be used for something like KVM. There is another stage of
> page table translations, so the one set up by Linux actually generates
> an intermediate physical address (IPA) which gets translated to the real
> PA in the second stage. The IPA is 40-bit wide.
I was only talking about the Virtualization Extensions, my impression from
the information that is publically available was that you'd only need
to set some mode bits differently in order to make the virtual address
space (I suppose that's what you call IPA) up to 40 bits instead of 32,
and you'd be able to have the guest use a 40 bit physical address space
from that.
Are there any significant differences to Linux between setting up page
tables for a 32 bit VA space or a 40 bit IPA space, other than the
size of the PGD?
Arnd
next prev parent reply other threads:[~2010-10-25 13:25 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-25 8:59 [RFC PATCH 00/18] ARM: Add support for the Large Physical Address Extensions Catalin Marinas
2010-10-25 8:59 ` [RFC PATCH 01/18] ARM: LPAE: Use PMD_(SHIFT|SIZE|MASK) instead of PGDIR_* Catalin Marinas
2010-10-25 8:59 ` [RFC PATCH 02/18] ARM: LPAE: Factor out 2-level page table definitions into separate files Catalin Marinas
2010-10-25 8:59 ` [RFC PATCH 03/18] ARM: LPAE: use u32 instead of unsigned long for 32-bit ptes Catalin Marinas
2010-10-25 8:59 ` [RFC PATCH 04/18] ARM: LPAE: Do not assume Linux PTEs are always at PTRS_PER_PTE offset Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 05/18] ARM: LPAE: Introduce L_PTE_NOEXEC and L_PTE_NOWRITE Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 06/18] ARM: LPAE: Introduce the 3-level page table format definitions Catalin Marinas
2010-10-25 11:15 ` Arnd Bergmann
2010-10-25 11:59 ` Catalin Marinas
2010-10-25 13:25 ` Arnd Bergmann [this message]
2010-10-25 16:18 ` Catalin Marinas
2010-10-25 18:25 ` Arnd Bergmann
2010-12-06 9:27 ` Christoffer Dall
2010-12-06 14:21 ` Arnd Bergmann
2010-10-25 9:00 ` [RFC PATCH 07/18] ARM: LPAE: Page table maintenance for the 3-level format Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 08/18] ARM: LPAE: MMU setup for the 3-level page table format Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 09/18] ARM: LPAE: Add fault handling support Catalin Marinas
2010-10-25 10:17 ` Kirill A. Shutemov
2010-10-25 10:35 ` Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 10/18] ARM: LPAE: Add context switching support Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 11/18] ARM: LPAE: Add SMP support for the 3-level page table format Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 12/18] ARM: LPAE: use phys_addr_t instead of unsigned long for physical addresses Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 13/18] ARM: LPAE: ensure dma_addr_t is the same size as phys_addr_t Catalin Marinas
2010-10-25 11:08 ` Arnd Bergmann
2010-10-25 11:32 ` Catalin Marinas
2010-10-25 12:01 ` FUJITA Tomonori
2010-10-25 12:31 ` Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 14/18] ARM: LPAE: mark memory banks with start > ULONG_MAX as highmem Catalin Marinas
2010-10-25 9:00 ` [RFC PATCH 15/18] ARM: LPAE: use phys_addr_t for physical start address in early_mem Catalin Marinas
2010-10-25 9:01 ` [RFC PATCH 16/18] ARM: LPAE: add support for ATAG_MEM64 Catalin Marinas
2010-10-25 9:01 ` [RFC PATCH 17/18] ARM: LPAE: define printk format for physical addresses and page table entries Catalin Marinas
2010-10-25 12:01 ` Kirill A. Shutemov
2010-10-25 9:01 ` [RFC PATCH 18/18] ARM: LPAE: Add the Kconfig entries Catalin Marinas
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=201010251525.09002.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.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